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PREFACE 



This publication provides customer 
engineers and other technical personnel 
with information describing the internal 
organization and operation of the FORTRAN 
IV (H) compiler. It is part of an inte- 
grated library of IBM System/360 Operating 
System Program Logic Manuals, other publi- 
cations required for an understanding of 
the FORTRAN IV (H) compiler are: 

IBM System/360 t Principles of Operation , 
Form A22-6821 

IBM System/ 3 60 Operating System; 

F0RTRAN_IV_Lanaua2§» Form C28-6515 

Introduction to Control Program Logic , 
Program Logic Manual , Form Y28-6605 

FORTRAN IV (G and H) Programmer _;;_s _Gu i d e , 
Form C28-6817~ 

Although not required, the following 
publications are related to this publica- 
tion and should be consulted: 

IBM System/ 360 Operating System: 

Sequenti a l Access Methods, Program Logic 
Manual , Form Y28-6604 

Concepts and Facilities , Form C28-6535 

Supervisor and DataManagement Macro 
I.llstEli££i2G;S, Form 028-6647 

Linkage Editor, Program Logic Manual , 
Form Y28-6610 

System Generation , Form C28-655U 

This manual consists of two sections. 

Section 1 is an introduction that 
describes the FORTRAN IV (H) compiler as a 



whole, including its relationship to the 
operating system. The major components of 
the compiler and the relationships among 
them are also described. 



Section 2 consists of a discussion of 
the major components. Each component is 
discussed in terms of its functions; the 
level of detail provided is sufficient to 
enable the reader to understand the general 
operation of the component. In the discus- 
sion of each function of a component, the 
routines that implement that function are 
identified by name. The inclusion of a 
compound form of the routine names provides 
a frame of reference for the comments and 
coding supplied in the program listing. 
The program listing for each identified 
routine appears on the microfiche card hav- 
ing the second portion of the compound name 
of that routine in its heading. For 
example, the routine referred to in this 
manual as STALL-IEKGST is listed on the 
microfiche card headed lEKGST, This sec- 
tion also discusses common data, such as 
tables, blocks, and work areas, but only to 
the extent required to understand the logic 
of the components. Flowcharts and routine 
directories are included at the end of this 
section. 



Following Section 2 are a number of 
appendixes, which contain descriptions of 
tables used by the compiler, intermediate 
text formats, a section on object-time 
library subprograms, the overlay structure 
of the compiler, and other reference 
material. 



If more detailed information is 
required, the reader should refer to the 
comments and coding in the FORTRAN IV (H) 
program listing. 
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SECTION 1: INTRODUCTION 



This section contains general informa- 
tion describing the purpose of the FORTRAN 
IV (H) compiler, its relationship to the 
operating system, its input/output data 
flow, its organization, and its overlay 
structure. 



PURPOSE OF THE COMPILER 



The IBM System/360 Operating System 
FORTRAN IV (H) compiler transforms source 
modules written in the FORTRAN IV language 
into object modules that are suitable for 
input to the linkage editor for subsequent 
execution on the System/360, At the user's 
option, the compiler produces optimized 
object modules (modules that can be 
executed with improved efficiency). 



THE COMPILER AND OPERATING SYSTEM/360 



INPUT/OUTPUT DATA FLOW 



The source modules to be compiled are 
read in from the SYSIN data set. Compiler 
output is placed on the SYSLIN, SYSPRINT, 
SYSPUNCH, SYSUTl, Or SYSUT2 data set, 
depending on the options specified by the 
FORTRAN programmer, (The SYSPRINT data set 
is always required for compilation. ) 



The overall data flow and the data sets 
used for the compilation are illustrated in 
Figure 1, 



COMPILER ORGANIZATION 



The IBM System/360 Operating System 
FORTRAN IV (H) compiler consists of the 
FORTRAN system director, four logical proc- 
essing phases (phases 10, 15, 20, and 25), 
and an error-handling phase (phase 30). 



The FORTRAN IV (H) compiler is a proc- 
essing program that communicates with the 
System/ 360 Operating System control program 
for input/output and other services. A 
general description of the control program 
is given in the publication IBM System/360 
Opera ting System; Introdu ction t o Control 
Program Logic, Program Logic Manual , Form 
Y28-6605. 

A compilation, or a batch of compila- 
tions, is requested using the job statement 
(JOB), the execute statement (EXEC), and 
data definition statements (DD), Cataloged 
procedures may also be used. A discussion 
of FORTRAN IV compilation and the available 
cataloged procedures is given in the publi- 
cation IBM_System/3 60 Operating System; 

FORTRAN IV_(G and H) Programmer* s Guide , 
Form C28-6817. 

The compiler receives control from the 
calling program (e.g., job scheduler or 
another program that calls, links to, or 
connects the compiler) . Once the compiler 
receives control, it communicates with the 
control program through the FORTRAN system 
director, a part of the compiler that con- 
trols compiler processing. After compiler 
processing is completed, control is 
returned to the calling program. 



Control is passed among the phases of 
the compiler via the FORTRAN system direc- 
tor. After each phase has been executed, 
the FORTRAN system director determines the 
next phase to be executed, and calls that 
phase. The flow of control within the com- 
piler is illustrated in Chart 00. (Charts 
are located at the end of Section 2.) 

The components of the compiler operating 
together produce an object module from a 
FORTRAN source module. The object module 
is acceptable as input to the linkage edi- 
tor, which prepares object modules for 
relocatable loading and execution. 

The object module consists of control 
dictionaries (external symbol dictionary 
and relocation dictionary) , text (repre- 
senting the actual machine instructions and 
data), and an END statement. The external 
symbol dictionary (ESD) contains the 
external symbols that have been defined or 
referred to in the source module. The 
relocation dictionary (RLD) contains infor- 
mation about address constants in the 
object module. 

The functions of the components of the 
compiler are described in the following 
paragraphs. 



Section 1 
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FORTRAN SYSTEM DIRECTOR 



The FORTRAN system director (FSD) con- 
trols compiler processing. It initializes 
compiler operation, calls the phases for 
execution, and distributes and keeps track 
of the main storage used during the compi- 
lation. In addition, the FSD receives the 
various input/output requests of the com- 
piler phases and submits them to the con- 
trol program. 



PHASE 10 



Phase 10 accepts as input (from the 
SYSIN data set) the individual source 
statements of the source module. If a 
source module listing is requested, the 
source statements are recorded on the SYS- 
PRINT data set. If the XREF option is 
selected, a two-part cross reference is re- 
corded on the SYSPRINT data set immediately 
following the source listing. If the EDIT 
option is selected, the source statements 
are recorded on the SYSUTl data set, which 
phase 20 uses as input to produce a struc- 
tured source listing. If the ID option is 
selected, calls and function references are 



assigned an internal statement number 
(ISN). 

Phase 10 converts each source statement 
into a form usable as input by succeeding 
phases. This usable input consists of an 
intermediate text representation (in 
operator-operand pair format) of each 
source statement. In addition, phase 10 
makes entries in an information table for 
the variables, constants, literals, state- 
ment numbers, etc. , that appear in the 
source statements. Phase 10 also places 
data about COMMON and EQUIVALENCE state- 
ments in the information table so that main 
storage space can be allocated correctly in 
the object module. During this conversion 
process, phase 10 also analyzes the source 
statements for syntactical errors. If 
errors are encountered, phase 10 passes to 
phase 30 (by making entries in an error 
table) the information needed to print the 
appropriate error messages. 



PHASE 15 



Phase 15 gathers additional information 
about the source module and modifies some 
intermediate text entries to facilitate 
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optimization by phase 20 and instruction 
generation by phase 25. Phase 15 is 
divided into two segments that perform the 
following functions: 

• The first segment translates phase 10 
intermediate text entries (in operator- 
operand pair format) representing 
arithmetic operations into a four-part 
format, which is needed for optimiza- 
tion by phase 20 and instruction- 
generation by phase 2 5. This part of 
phase 15 also gathers information about 
the source module that is needed for 
optimization by phase 20. 

• The second segment of phase 15 assigns 
relative addresses and, where neces- 
sary, address constants to the named 
variables and constants in the source 
module. This segment also converts 
phase 10 intermediate text (in 
operator-operand pair format) repre- 
senting DATA statements to a variable- 
initial value format, which makes later 
assignment of a constant value to a 
variable easier. 

Phase 15 also passes to phase 30 the 
information needed to print appropriate 
messages for any errors detected during 
phase 15 processing. (This is done by mak- 
ing entries in the error table. ) 



PHASE 20 



Phase 20 processing depends on whether 
or not optimization has been requested and, 
if so, the optimization level desired. 

If no optimization is specified, phase 
20 assigns registers for use during execu- 
tion of the object module. However, phase 
20 does not take full advantage of all 
registers and makes no effort to keep fre- 
quently used quantities in registers to 
eliminate the need for some machine 
instructions. 



If both the EDIT option and the second 
level of optimization are selected, phase 
20 produces a structured source program 
listing on the SYSPRINT data set. 



PHASE 25 



Phase 25 produces an object module from 
the combined output of the preceding phases 
of the compiler. 

The text information (instructions and 
data resulting from the compilation) is in 
a relocatable machine language format. It 
may contain unresolved external symbolic 
cross references (i.e., references to sym- 
bols that do not appear in the source 
module). The external symbol dictionary 
contains the information required by the 
linkage editor to resolve external symbolic 
cross references, and the relocation dic- 
tionary contains the information needed by 
the linkage editor to relocate the absolute 
text information. 

Phase 25 places the object module 
resulting from the compilation on the 
SYSLIN data set if the LOAD option is spe- 
cified, and on the SYSPUNCH data set if the 
DECK option is specified. Phase 25 pro- 
duces an object module listing on the 
SYSPRINT data set if the LIST option is 
specified. In addition, phase 25 produces 
a storage map if the MAP option is 
specified. 



PHASE 30 



Phase 30 is called after phase 25 
processing is completed only if errors are 
detected by previous phases. Phase 30 
records messages describing the detected 
errors on the SYSPRINT data set. 



If the first level of optimization is 
specified, phase 20 uses all available 
registers and keeps frequently used quanti- 
ties in registers wherever possible. Phase 
20 takes other measures to reduce the size 
of the object module, and provides informa- 
tion about operands to phase 25. 

If the second level of optimization is 
specified, phase 20 uses other techniques 
to make a more efficient object module. 
The net result of these procedures is to 
eliminate unnecessary instructions and to 
eliminate needless execution of 
instructions . 



STRUCTURE OF THE COMPILER 



The FORTRAN IV (H) compiler is struc- 
tured in a planned overlay fashion, which 
consists of 13 segments. One of these seg- 
ments constitutes the FORTRAN system direc- 
tor and is the root segment of the planned 
overlay structure. Each of the remaining 
12 segments constitutes a phase or a logic- 
al portion of a phase. A detailed discus- 
sion of the compiler's planned overlay 
structure is given in Appendix G. 



Section 1: Introduction 15 



SECTION 2: DISCUSSION OF MAJOR COMPONENTS 



The following paragraphs and associated 
flowcharts at the end of this section 
describe the major components of the FOR- 
TRAN IV (H) compiler. Each component is 
described to the extent necessary to 
explain its function (s) and its general 
operation. 



FORTRAN SYSTEM DIRECTOR 



options (e.g., SOURCE, MAP) specified for 
the compilation. If the compiler receives 
control as a result of a LINK macro 
instruction in another program, the parame- 
ter list may have a second entry, which is 
a pointer to the main storage area contain- 
ing substitute ddnames (i.e., ddnames that 
the user wishes to substitute for the 
standard ones of SYSIN, SYSPRINT, SYSPUNCH, 
SYSLIN, SYSUTl, and SYSUT2. 



The FORTRAN system director (FSD) con- 
trols compiler processing; its overall 
logic is illustrated in Chart 01. (For a 
complete list of FSD subroutines, see Table 
6.) The FSD receives control from the job 
scheduler if the compilation is defined as 
a job step in an EXEC statement. The FSD 
may also receive control from another pro- 
gram through use of one of the system macro 
instructions (CALL, LINK, or ATTACH) . 

The FSD: 

• Initializes the compiler. 

• Loads the compiler phases. 

• Distributes storage to the phases. 

• Processes input/output requests. 

• Generates entry code (initialization 
instructions) for main programs, sub- 
programs, and subprogram secondary 
entries. 

• Deletes compilation. 

• Terminates compilation. 



COMPILER INITIALIZATION 



COMPILER OPTIONS ; To determine the options 
specified for the compilation and to inform 
the various compiler phases of these 
options, the FSD scans and analyzes the 
storage area containing their images and 
sets indicators to reflect the ones speci- 
fied. These indicators are placed into the 
communication table — lEKAAA (see Appendix 
A, "Communication Table") during data field 
initialization. The various compiler 
phases have access to the communication 
table and, from the indicators contained in 
it, can determine which options have been 
selected for the compilation. 

S UBSTI TUTE DDNAMES; If the user wishes to 
substitute ddnames for the standard ones, 
the FSD must establish a correspondence 
between the DD statements having the sub- 
stitute ddnames and the DCBs (Data Control 
Blocks) associated with the ddnames to be 
replaced. To establish this necessary 
correspondence, the FSD scans the storage 
area containing the substitute ddnames, and 
enters each such ddname into the DCBDDNM 
field of the DCB associated with the 
standard ddname it is to replace. 



The initialization of compiler proces- 
sing by the FSD consists of two steps: 

• Parameter processing. 

• Data field initialization. 



Parameter Processing 



When the FSD is given control, the 
address of a parameter list is contained in 
a general register. If the compiler 
receives control as a result of either an 
EXEC statement in a job step or an ATTACH 
or CALL macro instruction in another pro- 
gram, the parameter list has a single 
entry, which is a pointer to the main 
storage area containing an image of the 



Data Field Initialization 



Data field initialization affects the 
commvinication table, which is a central 
gathering area used to communicate informa- 
tion among the phases of the compiler. The 
table contains information such as: 

• User specified options. 

• Pointers indicating the next available 
locations within the various storage 
areas. 

• Pointers to the initial entries in the 
various types of chains (see Appendix 
A, "Information Table" and "Appendix B, 
Intermediate Text"). 
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• Name of the source module being 
compiled. 

• An indication of the phase currently in 
control. 

The various fields of the communication 
table, which are filled during a compila- 
tion, must be initialized before the next 
compilation. To initialize this region, 
the FSD clears it and places the option 
indicators into the fields reserved for 
them. 



PHASE LOADING 



The FSD loads and passes control to each 
phase of the compiler by means of a 
standard calling sequence. The execution 
of the call causes control to be passed to 
the overlay supervisor, which calls program 
fetch to read in the phase. Control is 
then returned to the overlay supervisor, 
which branches to the phase. The phases 
are called for execution in the following 
sequence: phase 10, phase 15, phase 20, 
and phase 25. However, if errors are 
detected by previous phases, phase 30 is 
called after the completion of phase 25 
processing. 



Intermediate Text") pointers to both the 
beginning and end of the allocated storage 
space. If the subblock is allocated for 
phase 10 normal text or for the information 
table, the pointers are returned in the 
communication table. If the subblock is 
allocated for a phase 10 text type other 
than normal text, the pointers are returned 
via the storage area PIOA-IEKCAA. After 
the storage has been allocated, the FSD 
adjusts the end of the information table 
downward by the size of the allocated sub- 
block. This process is repeated for each 
phase 10 request for main storage space, 

Subblocks to contain phase 10 text or 
dictionary entries are allocated in the 
order in which requests for main storage 
are received, (When phase 10 completely 
fills one subblock with text entries, it 
requests another, ) A request for a sub- 
block to contain a particular type of entry 
may immediately follow a request for a sub- 
block to contain another type of entry. 
Consequently, subblocks allocated to con- 
tain the same type of entries may be scat- 
tered throughout main storage. The FSD 
must keep track of the subblocks so that, 
at the completion of phase 10 processing, 
unused or unnecessary storage may be allo- 
cated to phase 15, 



Pha se 15 S torage 



STORAGE DISTRIBUTION (CHART 02) 



Phases 10, 15, and 20 require main 
storage space in which to construct the 
information table (see Appendix A, "Infor- 
mation Table") and to collect intermediate 
text entries. These phases obtain this 
storage space by submitting requests to the 
FSD (at entry point lEKAGC), which allo- 
cates the required space, if available, and 
returns to the requesting phase pointers to 
both the beginning and end of the allocated 
storage space. 



Phase 10 storage 



Phase 10 can use all of the available 
storage space for building the information 
table and for collecting text entries. At 
each phase 10 request for main storage in 
which to collect text entries or build the 
information table, the FSD reallocates a 
portion (i.e., a subblock) of the storage 
for text collection, and returns to phase 
10 either via the communication table or 
the storage area PIOA-IEKCAA (depending 
upon the type of text to be collected in 
the subblock; see Appendix B, "Phase 10 



Phase 15, in collecting the text or dic- 
tionary entries that it creates, can use 
only those portions of main storage that 
are (1) unused by phase 10, or (2) occupied 
by phase 10 normal text entries that have 
been processed by phase 15. The FSD first 
allocates all unused storage (if necessary) 
to phase 15, If this is not sufficient, 
the FSD then allocates the storage occupied 
by phase 10 normal text entries that have 
undergone phase 15 processing. If either 
of these methods of storage allocation 
fails to provide enough storage for phase 
15, the compilation is terminated. 

Pointers to both the beginning and end 
of the allocated subblock portion are 
passed to phase 15 via the communication 
table. If an additional request is 
received after the last subblock portion is 
allocated, the FSD determines the last 
phase 10 normal text entry that was 
processed by phase 15, The FSD then frees 
and allocates to phase 15 the portion of 
storage occupied by phase 10 normal text 
entries between the first such text entry 
and the last entry processed by phase 15. 

Phase 15 S torage Inventory ; After the pro- 
cessing of PHAZ15, the first segment of 
phase 15, is completed, the FSD recovers 
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the subblocks that were allocated to phase 
10 normal text. These subblocks are 
chained as extensions to the storage space 
available at the completion of PHAZ15 pro- 
cessing. The chain, which begins in the 
FSD pointer table, connecting the various 
available portions of storage is scanned 
and when a zero pointer field is encoun- 
tered, a pointer to the first subblock 
allocated to phase 10 normal text is placed 
into that field. The chain connecting the 
various subblocks allocated to phase 10 
normal text is then scanned and when a zero 
pointer field is encountered, a pointer to 
the first subblock allocated to SF skeleton 
text is placed into that field. Once the 
subblocks are chained in this manner, they 
are available for allocation to CORAL, the 
second segment of phase 15, and to phase 
20. 



After the processing of CORAL is com- 
pleted, the FSD likewise recovers the sub- 
blocks allocated for phase 10 special text. 
The chain connecting the various portions 
of available storage space is scanned and 
when a zero pointer field is encountered, a 
pointer to the first subblock allocated for 
phase 10 special text is placed into that 
field. After the subblocks allocated for 
phase 10 special text are linked into the 
chain as described above, they, as well as 
all other portions of storage space in the 
chain, are available for allocation to 
phase 20. 



Phase 20 Storage 



Each phase 20 request for storage space 
is satisfied with a portion of storage 
available at the completion of CORAL pro- 
cessing. The portions of storage are allo- 
cated to phase 20 in the order in which 
they are chained. Pointers to both the 
beginning and end of the storage allocated 
to phase 20 for each request are placed 
into the communication table. 



Regue s t F orma t 



Phase requests for input/output services 
are made in the form of READ/WRITE state- 
ments requiring a FORMAT statement. The 
format codes that can appear in the FORMAT 
statement associated with such READ/WRITE 
requests are a subset of those available in 
the FORTRAN IV language. The subset con- 
sists of the following codes: Iw (output 
only) , Tw, Aw, wX, wH, and Zw (output 
only) . 



Request Processing 



To process input/output requests from 
the compiler phases, the FSD performs a 
series of operations, which are a subset of 
those carried out by the lEKFCOMH/IEKFIOCS 
combination (see Appendix E) to implement 
sequential READ/WRITE statements requiring 
a format. 



GENERATION OF INITIALIZATION INSTRUCTIONS 



The FSD subroutine lEKTLOAD works with 
STALL to generate the machine instructions 
for entry into a program. These instruc- 
tions are referred to as initialization 
instructions and are divided into three 
catagories: 

• Entry coding for a main program. 

• Entry coding for subprograms with no 
secondary entry points. 

• Main entry coding for subprograms with 
secondary entry points. 

Once generated, these instructions are 
entered into TXT records (see "Phase 25, 
Text Information" for a discussion of TXT 
records) . 



Entry Coding for a Main Program 



INPUT/OUTPUT REQUEST PROCESSING 



The FSD routine lEKFCOMH receives the 
input/output requests of the compiler 
phases and submits them to QSAM (Queued 
Sequential Access Method) for implementa- 
tion (see the publication IBM System/ 360 

02erating_Systemj^ §£a!^§Iltial_Access 

Methods , Progr am_Logi c _Manua 1 , Form 

Y28-6604). 



The initialization instructions 
generated by subroutine lEKTLOAD for a main 
program perform the following functions : 

• Branch past the eight-byte name field 
to the store multiple instruction, 

• Save the contents of registers 14 
through 12 in the save area of the 
calling program. 
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• Load the address of the prologue into 
register 2 and the address of the save 
area into register 3. 



• Store the location of the called pro- 
gram' s save area into the third word of 
the calling program's save area. 

• Store the location of the calling pro- 
gram' s save area into the second word 
of the called program's save area. 

• Branch to the prologue. (For an 
explanation of prologue and epilogue, 
see "Phase 25, Prologue and Epilogue 
Generation. ") 



The prologue instructions perform the 
following functions: 



• Load register 12, if register 12 is 
used. 



• Load register 15 for the following call 
to IBCOM. 



• Call IBCOM for main program 
initialization. 



• Load register 13 with the address of 
the called program's save area. 



• Branch to the first instruction in the 
body of the program. 



Entry Coding for Subprograms with No 
Secondary Entry Points 



The initialization instructions 
generated by subroutine lEKTLOAD for the 
entry points into a subprogram with no 
secondary entry points perform the follow- 
ing functions: 

• Branch past the eight-byte name field 
to the store multiple instruction. 

• Save the contents of general registers 
14 through 12 in the save area of the 
calling program. 

• Load the address of the calling pro- 
gram's save area into register 4. 

• Load the address of the prologue into 
register 12 and the address of the save 
area into register 13. 



• Store the location of the calling pro- 
gram's save area into the second word 
of the called program' s save area. 

• Store the location of the called pro- 
gram's save area into the third word of 
the calling program' s save area. 

• Branch to the prologue. (For an 
explanation of prologue and epilogue, 
see "Phase 25, Prologue and Epilogue 
Generation. ") 

The prologue instructions perform the 
following functions: 

• Initialize call by value arguments (if 
any) and also initialize adcons for 
call by name argtiments (if any). 

• Branch to the first instruction in the 
body of the called program. 



Main E ntry Co ding for Subprog r ams wit h 
Secondary Entry Points 



The initialization instructions 
generated by subroutine lEKTLOAD for the 
main entry point into a subprogram with 
secondary entry points perform the follow- 
ing functions : 

• Branch past the eight-byte name field 
to the store multiple instruction. 

• Save the contents of registers 14 
through 12 in the save area of the 
calling program. 

• Load the address of the prologue into 
register 2 and the address of the epi- 
logue into register 3. 

• Ijoad the location of the calling pro- 
gram's save area into register 4. 

• Load the location of the called pro- 
gram's save area into register 13. 

• Store the address of the epilogue into 
the first word of the called program' s 
save area and the location of the 
calling program's save area into the 
second word of the called program's 
save area. 

• Store the location of the called pro- 
gram's save area into the third word of 
the calling program' s save area. 

• Branch to the prologue. 

The main entry prologue instructions 
(generated by phase 25) perform the same 
functions described previously under "Entry 
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Coding for Subprograms with No Secondary 
Entry Points . " 



entry point, equivalent instructions will 
be generated. 



Subprogram Secondary Entry Coding 



DELETION OF A COMPILATION 



This coding is generated entirely by 
phase 25 but is mentioned here for 
completeness. The requirements of second- 
ary entry coding are essentially the same 
as main entry coding. For this reason many 
of the main entry instructions are used by 
phase 25 through an unconditional branch 
into that section of code. Main entry 
instructions that precede and include the 
instruction which loads the prologue and 
epilogue addresses cannot be used, since 
each secondary entry point has its own 
associated prologue and epilogue. There- 
fore, secondary entry instructions perform 
the following functions : 

• Branch past the eight-byte name field 
to the store multiple instruction. 

• Save the contents of registers 14 
through 12 in the save area of the 
calling program. 

• Load the address of the prologue into 
register 2 and the address of the epi- 
logue into register 3. 

• Load register 15 with the address of 
the instruction in the main entry cod- 
ing that loads register 4. 

• Branch into the main entry coding. 

The secondary entry prologue instruc- 
tions (generated by phase 25) perform the 
same functions described previously for 
subprogram main entry coding, except that 
the branch is directed to the desired entry 
point in the body of the called program 
rather than the first instruction. 

Subprogram secondary entry coding does 
not occupy storage within the "Initializa- 
tion Instructions" section of text informa- 
tion. That section is reserved for: 

• Main program entry coding, if the 
source module being compiled is a main 
program. 

• Subprogram main entry coding, if a sub- 
program is being compiled. 

The secondary entry coding is generated for 
each occurrence of an ENTRY statement, fol- 
lowed immediately by its associated prolo- 
gue and epilogue. Secondary entry coding 
follows the main prologue and epilogue 
which, in turn, follow the main body of the 
program. For each additional secondary 



The FSD deletes a compilation if an 
error of error level code 16 (see the pub- 
lication IBM System/360 Operating System; 
FORTRAN IV (G and H) Pro gramme r's Guide , 
Form C28-6817) is detected during the 
execution of a processing phase. 

The phase detecting the error passes 
control to the FSD at entry point SYSDIR- 
IEKAA9. If the error was detected by phase 
10, the FSD del6?tes the compilation by hav- 
ing phase 10 read records (without process- 
ing them) until the END statement is 
encountered. If the error was encountered 
in a phase other than phase 10, the FSD 
simply deletes the compilation. 



COMPILER TERMINATION 



The FSD terminates compiler processing 
when an end-of-file is encountered in the 
input data stream or when a permanent 
input/output error is encountered. If, 
after the deletion of a compilation or 
after a source module has been completely 
compiled, the first record read by the FSD 
from the SYSIN data set contains an end-of- 
file indicator, control is passed to the 
FSD (at the entry point ENDFILE) , which 
terminates compiler processing by returning 
control to the operating system. If a per- 
manent error is encountered during the 
servicing of an input/output request of a 
phase, control is passed to the FSD (at 
entry point IBCOMRTN) , which writes a mes- 
sage stating that both the compilation and 
job step are deleted. The FSD then returns 
control to the operating system. In either 
of the above cases, the FSD passes to the 
operating system as a condition code the 
value of the highest error level code 
encountered during compiler processing. 
The value of the code is used to determine 
whether or not the next job step is to be 
performed. 



PHASE 10 



The FSD reads the first record of the 
source module and passes its address to 
phase 10 via the communication table. 
Phase 10 converts each FORTRAN source 
statement into usable input to subsequent 
phases of the compiler; its overall logic 
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is illustrated in Chart 03. Phase 10 
conversion produces an intermediate text 
representation of the source statement and/ 
or detailed information describing the 
variables, constants, literals, statement 
numbers, data set reference numbers, etc. , 
appearing in the source statement. During 
conversion, the source statement is ana- 
lyzed for syntactical errors. 

The intermediate text is a strictly 
defined internal representation (i.e., 
internal to the compiler) of a source 
statement. It is developed by scanning the 
source statement from left to right and by 
constructing operator-operand pairs. In 
this context, operator refers to such ele- 
ments as commas, parentheses, and slashes, 
as well as to arithmetic, relational, and 
logical operators. Operand refers to such 
elements as variables, constants, literals, 
statement numbers, and data set reference 
ntimbers. An operator-operand pair is a 
text entry, and all text entries for the 
operator-operand pairs of a source state- 
ment are the intermediate text representa- 
tion of that statement. 



real, integer, etc. Such information is 
entered into the information table. 



The information table consists of five 
components, as follows: 

• The dictionary contains information 
describing the constants and variables 
of the source module. 

• The s tat ement number/ar ray tabl e con- 
tains information describing the state- 
ment numbers and arrays of the source 
module. 

• The common table contains information 
describing COMMON and EQUIVALENCE 
declarations. 

• The literal table contains information 
describing the literals of the source 
module. 

• The branch table contains information 
describing statement numbers that 
appear in computed GO TO statements. 



The following six types of intermediate 
text are developed by phase 10 : 

• Nor mal text is the intermediate text 
representation of source statements 
other than DATA, NAMELIST, DEFINE FILE, 
FORMAT, and statement functions. 

• Data tex t is the intermediate text 
representation of DATA statements and 
initialization values in type 
statements. 

• Namelist text is the intermediate text 
representation of NAMELIST statements. 

• 2®fill§_fil^_t§2£t is the intermediate 
text representation of DEFINE FILE 
statements . 

• Format text is the intermediate text 
representation of FORMAT statements. 

• SF skeleton text is the intermediate 
text representation of statement func- 
tions using sequence numbers as 
operands of the intermediate text 
entries. The sequence numbers replace 
the dummy arguments of the statement 
functions. This type of text is, in 
effect, a "skeleton" macro instruction. 

The various text types are discussed in 
detail in Appendix B, "Intermediate Text. " 

The detailed information describing 
operands includes such facts as whether a 
variable is dimensioned (i.e., an array) 
and whether the elements of an array are 



A detailed discussion of the information 
table is given in Appendix A, "Information 
Table. " 

The intermediate text and the informa- 
tion table complement each other in the 
actual code generation by the subsequent 
phases. The intermediate text indicates 
what operations are to be carried out on 
specific operands; the information table 
provides the detailed information describ- 
ing the operands that are to be processed. 



SOURCE STATEMENT PROCESSING 



To process source statements, each rec- 
ord (one card image) of the source module 
is first read into an input buffer by a 
preparatory subroutine (GETCD-IEKCGC) . If 
a source module listing is requested, the 
record is recorded on an output data set 
(SYSPRINT). If both the EDIT option and 
the second level of optimization (0PT=2) 
are selected, the record and some control 
information used by phase 20 to produce a 
structured source listing are recorded on 
the SYSUTl data set. Records are moved to 
an intermediate buffer until a complete 
source statement resides in that buffer. 
Unnecessary blanks are eliminated from the 
source statement, and the statement is 
assigned a classification code. A dis- 
patcher subroutine (DSPTCH-IEKCDP) deter- 
mines from the code which subroutine is to 
continue processing the source statement. 
Control is then passed to that siibroutine, 
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which converts the source statement to its 
intermediate text representation and/or 
constructs information table entries 
describing its operands (see Table 7 for a 
list of the subroutines that process each 
type of statement). After the entire 
source statement has been processed, the 
next statement is read and processed as 
described above. The recognition of the 
END statement causes phase 10 to complete 
its processing and retxirn control to the 
FSD, which then calls phase 15 for 
execution. 



PreparatorY_Subroutine 



The preparatory subroutine (GETCD- 
lEKCGC) reads each source statement, re- 
cords it on the SYSPRINT data set if the 
SOURCE option is selected, and on the 
SYSUTl data set if the EDIT option and the 
second level of optimization are selected, 
packs and classifies it, and assigns it an 
internal statement niimber (ISN)^. Packing 
eliminates unnecessary blanks, which may 
precede the first character, follow the 
last character, or be imbedded within the 



The functions of phase 10 are performed 
by six groups of subroutines : 



• Dispatcher subroutine 

• Preparatory subroutine 

• Keyword subroutine (s) 

• Arithmetic subroutine (s) 

• Utility subroutine (s) 

• STALL- lEKGST subroutine 



D ispatcher Subrouti ne 



The dispatcher subroutine (DSPTCH- 
lEKCDP) controls phase 10 processing. Upon 
receiving control from the FSD, the DSPTCH- 
lEKCDP subroutine initializes phase 10 
processing and then calls the preparatory 
subroutine (GETCD-IEKCGC) to read and pre- 
pare the first source statement. After the 
statement is prepared, control is returned 
to DSPTCH-IEKCDP, which determines whether 
or not a statement number is associated 
with the source statement being processed. 
If there is a statement number, the DSPTCH- 
IEKCDP subroutine constructs a statement 
number entry (see Appendix A, "Information 
Table") for the statement number. A text 
entry for the statement nximber is also 
created. The DSPTCH-IEKCDP subroutine then 
determines, from the classification code 
assigned to the source statement (see "Pre- 
paratory Subroutine"), which subroutine 
(either keyword or arithmetic) is to con- 
tinue the processing of the statement, and 
passes control to that subroutine. When 
the source statement is completely proc- 
essed, control is returned to the DSPTCH- 
IEKCDP subroutine, which calls the prepara- 
tory subroutine to read and prepare the 
next source statement. 
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source statement. Classifying assigns a 
code to each type of source statement. The 
code indicates to the DSPTCH-IEKCDP subrou- 
tine which subroutine is to continue proc- 
essing the source statement. A description 
of the classifying process, along with 
figures illustrating the two tables (the 
keyword pointer table and the keyword 
table) used in this process, is given in 
Appendix A, "Classification Tables." The 
ISN assigned to the source statement is an 
internal sequence number used to identify 
the source statement. The source statement 
and classification information about the 
source statement reside in the storage 



^Logical IF statements are assigned two 
internal statement numbers. The IF part 
is given the first number and the "trail- 
ing" statement is given the next. 
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areas y NCDIN and NCARD of the phase 10 com- 
mon area, as illustrated in Figure 2. 



Keyword Subroutine (s) 



A keyword subroutine exists for each 
keyword source statement. A keyword source 
statement is any permissible FORTRAN source 
statement other than an arithmetic state- 
ment or a statement function. The function 
of each keyword subroutine is to convert 
its associated keyword source statement (in 
NCDIN) into input usable by subsequent 
phases of the compiler. These subroutines 
make use of the utility subroutines and, at 
time?, the arithmetic subroutines in per- 
forming their functions. To simplify the 
discussion of these subroutines, they are 
divided into two groups : 

1. Those that construct only information 
table entries. 

2. Those that construct information table 
entries and develop intermediate text 
representations . 

Table En€ry Subroutines : Only one keyword 
subroutine belongs to this group (see Table 
8). It is associated with a COMMON, DIMEN- 
SION, EQUIVALENCE, or EXTERNAL keyword 
statement. 

This subroutine scans its associated 
statement (in NCDIN) from left to right and 
constructs appropriate information table 
entries for each of the operands of the 
statement. The types of information table 
entries that can be constructed by these 
subroutines are: 

• Dictionary entries for variables and 
external names. 

• Common block name entries for common 
block names. 

• Equivalence group entries for equiva- 
lence groups, 

• Equivalence variable entries for the 
variables in an equivalence group. 

• Dimension entries for arrays. 

The formats of these entries are given 
in Appendix A, "Information Table, " 

Table Entry and Text S ub routines ; The key- 
word subroutines, other than the table 
entry subroutine, belong to this group (see 
Table 8), Each of these subroutines con- 
verts its associated statement by develop- 
ing an intermediate text representation of 
the statement, which consists of text 
entries in operator-operand pair format. 



and constructing information table entries 
for the operands of the statement. The 
processing performed by these subroutines 
is similar and is described in the follow- 
ing paragraphs. 

Upon receiving control from the DSPTCH- 
lEKCDP s\abroutine, the keyword subroutine 
associated with the keyword statement being 
processed places a special operator into 
the te3tt area. This operator is referred 
to as a primary adjective code and defines 
the type (e, g, , DO, ASSIGN) of the state- 
ment, A left-to-right scan of the source 
statement is then initiated. The first 
operand is obtained, an information table 
entry is constructed for the operand and 
entered into the information table (only if 
that operand was not previously entered) , 
and a pointer to the entry' s location in 
that table is placed into the text area. 
The mode (e,g, , integer, real) and type 
(e,g,, negative constant, array) of the 
operand are then placed into text. 

Scanning is resumed and the next opera- 
tor is obtained and placed into the text 
area. The next operand is then obtained, 
an information table entry is constructed 
for the operand and entered into the infor- 
mation table (again, only if that operand 
was not previously entered) , and a pointer 
to the entry" s location is placed into the 
text entry work area. The mode and type of 
the operand are placed into the work area. 
The text entry is then placed into the next 
available location in the subblock allo- 
cated for text entries of the type being 
created. 

This process is terminated upon recogni- 
tion of the end of the statement, which is 
marked by a special text entry. The spe- 
cial text entry contains an end mark opera- 
tor and the ISN of the source statement as 
an operand. 

Note: Certain keyword subroutines in this 
group, namely those that process statements 
that can contain an arithmetic expression 
(e.g, , IF and CALL statements) and those 
that process statements that contain I/O 
list items (e.g,, READ/WRITE statements), 
pass control to the arithmetic subroutines 
to complete the processing of their asso- 
ciated keyword statements. 



Arithmetic Subroutine (s) 



The arithmetic subroutine or subroutines 
(see Table 8) receive control from the 
DSPTCH-IEKCDP subroutine, or from various 
keyword sxibroutines. These subroutines 
make use of the utility subroutines in per- 
forming their functions, which are to: 
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• Process arithmetic statements, 

• Process statement functions. 

• Complete the processing of certain key- 
word statements (READ, WRITE, CALL, and 
IF). 

Arithmetic subroutines are processed 
according to their functions, as follows: 

Arithmetic Statement Processing; In pro- 
cessing an arithmetic statement, the arith- 
metic subroutines develop an intermediate 
text representation of the statement, and 
construct information table entries for its 
operands. These subroutines accomplish 
this by following a procedure similar to 
that described for keyword (table entry and 
t ext ) s ubr out ine s . 

If one operator is adjacent to another, 
the first operator does not have an asso- 
ciated operand. In the example A=B(I)+C, 
the operator + has variable C as its asso- 
ciated operand, whereas the operator ) has 
no associated operand. If an operator has 
no associated operand, it is assumed that 
the operand is a zero (null). 

Statement Function Processing ; In convert- 
ing a statement function to usable input to 
subsequent phases of the compiler, the 
arithmetic subroutines develop an interme- 
diate text representation of the statement 
function using sequence numbers as replace- 
ments for dummy arguments. These subrou- 
tines also construct information table 
entries for those operands that appear to 
the right of the equal sign and that do not 
correspond to dummy arguments. The follow- 
ing paragraphs describe the processing of a 
statement function by the arithmetic 
subroutines. 

When processing a statement function, 
the arithmetic subroutines : 

• Scan the portion of the statement func- 
tion to the left of the equal sign, 
obtain each dummy argument, assign each 
dummy argument a sequence number (in 
ascending order) , and save the dummy 
arguments and their associated sequence 
numbers for subsequent use. 

• Scan the portion of the statement func- 
tion to the right of the equal sign and 
obtain the first (or next) operand. 

• Determine whether or not the operand 
corresponds to a dummy argtiment. If it 
does correspond, its associated 
sequence number is placed into the text 
area. If it does not correspond, a 
dictionary entry for the operand is 
constructed and entered into the infor- 
mation table, and a pointer to the 



entry' s location is placed into the 
text area. (An opening parenthesis is 
used as the operator of the first text 
entry developed for each statement 
function and a closing parenthesis is 
used as the operator of the last text 
entry developed for each statement 
function, ) 

• Resume scanning, obtain the next opera- 
tor, and place it into the text area. 

• Obtain the operand to the right of this 
operator and process it as described 
above. 

Key word Stat ement Completion; In addition 
to processing arithmetic statements and 
statement functions, the arithmetic subrou- 
tines also complete the processing of key- 
word statements that may contain arithmetic 
expressions or that contain I/O list items. 
The keyword subroutine associated with each 
such keyword statement performs the initial 
processing of the statement, but passes 
control to the arithmetic subroutines at 
the first possible occurrence of an arith- 
metic expression or an I/O list item, (For 
example, the keyword subroutine that proc- 
esses CALL statements passes control to the 
arithmetic subroutines after it has pro- 
cessed the first opening parenthesis of the 
CALL statement, because the argument that 
follows this parenthesis may be in the form 
of an arithmetic expression, ) The arith- 
metic subroutines complete the processing 
of these keyword statements in the normal 
manner. That is, they develop text entries 
for the remaining operator-operand pairs 
and construct information table entries for 
the remaining operands. 



Utility S ubro utine (s) 



The utility subroutines (see Table 8) 
aid the keyword, arithmetic, and DSPTCH- 
lEKCDP subroutines in performing their 
functions. The utility subroutines are 
divided into the following groups: 

• Entry placement subroutines. 

• Text generation subroutines, 

• Collection subroutines, 

• Conversion subroutines. 

Entry Pla cement Sub routi nes ; The utility 
subroutines in this group place the various 
types of entries constructed by the key- 
word, arithmetic, and DSPTCH-IEKCDP subrou- 
tines into the tables or text areas (i.e., 
subblocks) reserved for them. 

Text Gen er ati on Subr outines ; The utility 
subroutines in this group generate text 
entries (supplementary to those developed 
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by the keyword and arithmetic subroutines) 
that: 

• Control the execution of implied DOs 
appearing in input/output statements, 

• Increment DO indexes and test them 
against their maximum values. 

• Signify the end of a source statement. 



Collection Subroutines ; These utility sub- 
routines perform such functions as gather- 
ing the next group of characters (i.e., a 
string of characters bounded by delimiters) 
in the source statement being processed, 
and aligning variable names on a word 
boundary for comparison to other variable 
names. 



Conversion Subroutines ; These utility sub- 
routines convert integer, real, and complex 
constants to their binary equivalents. 



• Setting aside space in the object 
module for the problem program save 
area and for computed GO TO statement 
branch tables created by phase 10. 

• Checking the statement number section 
of the information table for undefined 
statement numbers. 

• Rechaining variables in the dictionary 
by sorting alphabetically the entries 
in each chain, 

• Assigning coordinates based on the 
usage count set by phase 10 when the 
OPT option is greater than zero. 

• Processing common entries in the infor- 
mation table by computing the displace- 
ment of each variable in the common 
block from the start of the common 
block. 

• Processing equivalence entries in the 
information table. 



Subroutine STALL-IEKGST (Chart OH) 



The STALL-IEKGST subroutine completes 
phase 10 processing by: 

• Generating entry code for the object 
module. 

• Translating phase 10 format text into 
object code for the object module and 
freeing space formerly occupied by the 
format text. 

• Checking to see if any literal data 
text exists and, if it does, generating 
object code for the literal data text. 

• Processing any equivalence entries that 
were equivalenced before being 
dimensioned. 



Generat ing FO RMAT Cod e : If the source 
module contains READ/WRITE statements 
requiring FORMAT statements, the associated 
phase 10 format text must be put into a 
form recognizable by IHCFCOMH. The STALL- 
IEKGST subroutine calls subroutine FORMAT- 
lEKTFM which develops the necessary format 
by obtaining the phase 10 intermediate text 
representation of each FORMAT statement, 
and translating each element (e.g., H for- 
mat code and field count) of the statement 
according to Table 1. The FORMAT-IEKTFM 
subroutine enters the translated statement 
along with its relative address into TXT 
records. It also inserts the relative 
address of the translated statement into 
the address constant for the statement num- 
ber associated with the FORMAT statement. 
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Processing Equivalenc e E ntr ies : The STALL- 
lEKGST subroutine completes the processing 
of any equivalence entries in the informa- 
tion table that were not completed by prior 
routines in phase 10. These equivalence 
entries are the ones that were equivalenced 
before being dimensioned. The STALL- lEKGST 
subroutine computes displacements for each 
variable in the equivalence group. 



Process ing Literal Co nst ants Used a s Argu - 
ments ; The STALL- lEKGST subroutine checks 
a pointer in the communication table (NPTR 
(1,27)) to see whether or not there are 
literal constants to process. If there 
are, the STALL-IEKGST subroutine calls lEK- 
TLOAD and passes to it the location and 
length of the literal string that is used 
by the lEKTLOAD subroutine to generate lit- 
eral text in the object module. All liter- 
al constants used as arguments are put on a 
double word boundary. 

The STALL-IEKGST subroutine follows the 
chain in the literal constant dictionary 
entry and continues to call subroutine lEK- 
TLOAD to process this text. After all the 
literal data text has been generated, the 
STALL-IEKGST subroutine adjusts the loca- 
tion counter by the amount of text 
generated. Literals used in DATA state- 



ments are not chained, and are not pro- 
cessed until CORAL is invoked. 



Re serving Space for the Save Area ; The 
STALL-IEKGST subroutine sets aside 76 bytes 
for the save area of the program being 
compiled. 

Space in the object module for branch 
tables created by phase 10 for computed GO 
TO statements is also reserved by the 
STALL-IEKGST subroutine. 

Checking for Undefined Statement Numbers ; 
The STALL-IEKGST subroutine performs a dic- 
tionary scan for undefined statement num- 
bers. This action is taken to ensure that 
every statement number that is referred to 
is also defined. The STALL-IEKGST subrou- 
tine scans the chain of statement number 
entries in the information table (see 
Appendix A: "Statement Number/Array 
Table") and examines a bit in the byte A 
usage field of each such entry. This bit 
is set by phase 10 to indicate whether or 
not it encountered a definition of that 
statement number. If the bit indicates 
that the statement number is not defined, 
the STALL-IEKGST subroutine places an entry 
in the error table for later processing by 
phase 30. 
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Rechaininq Entrie s for Variables : The 
STALL-IEKGST subroutine scans dictionary 
entries for variables. Previously executed 
routines in phase 10 sorted each variable 
chain alphabetically and left the pointer 
at the mid- item of the chain (for dic- 
tionary search speed) . The STALL-IEKGST 
subroutine resets the pointer to the first 
(alphabetically lowest) item in the chain. 
The rechaining frees storage in each entry 
for later use by CORAL in phase 15. It 
then sets the adcon field of each dic- 
tionary entry for a variable to zero. The 
STALL-IEKGST subroutine also constructs 
dictionary entries for the imaginary parts 
of complex variables and constants. 

Assigning Coordinates ; The STALL-IEKGST 
subroutine calls subroutine lEKKOS which 
assigns coordinates to variables and con- 
stants in the following manner: 

• The first 59 unique variables and/or 
constants that appear in the text 
created by phase 10 are assigned coor- 
dinates 2 through 60, respectively.^ 
The coordinates are assigned in order 
of increasing coordinate niamber. (A 
coordinate between 2 and 60 may be 
assigned to a base variable if fewer 
than 59 unique variables and constants 
appear in the text. ) 

• The next 20 unique variables are 
assigned coordinates 61 through 80, 
respectively. The coordinates are 
assigned in order of increasing coor- 
dinate number. (If constants are 
encountered after coordinate 60 has 
been assigned, they are not assigned 
coordinates. ) 

• The coordinates 81 through 128 are 
reserved for assignment to base 
variables (see "Adcon and Base Variable 
Assignment" under "CORAL Processing"). 

Subroutine lEKKOS assigns to the first 
variable or constant in phase 10 text a 
coordinate number of 2, which indicates 
that the usage information for that vari- 
able or constant, regardless of the block 
in which it appears, is to be recorded in 
bit position 2 of the MVS, MVF, and MVX 
fields. The lEKKOS subroutine assigns to 
the second variable or constant a coordin- 
ate number of 3 and records its usage 
information in bit position 3 of the three 
fields. Subroutine lEKKOS continues this 



^The coordinate 1 is assigned to items such 
as unit numbers (i.e., data set reference 
numbers), complex variables in COMMON, 
arrays that are equivalenced, variables 
that are equivalenced to arrays, and 
variables that are equivalenced to 
variables of different modes. 



process until coordinate 60 has been 
assigned to a variable or constant. When 
coordinate number 60 has been assigned, the 
lEKKOS subroutine only assigns coordinates 
to the next 20 unique variables. Subrou- 
tine lEKKOS does not assign coordinates to 
or gather usage information for unique con- 
stants encountered after coordinate number 
60 has been assigned. It assigns these 
variables coordinates 61 through 80, 
respectively. It records the usage infor- 
mation for each variable at the assigned 
bit location in the three fields. The lEK- 
KOS subroutine does not assign coordinates 
to or gather usage information for unique 
variables encountered after coordinate num- 
ber 80 has been assigned. 

Subroutine lEKKOS uses a combination of 
the MCOORD vector, the MVD table, and the 
byte-C usage fields of the dictionary 
entries (see Appendix A, "Dictionary") to 
assign, keep track of, and record coordin- 
ate numbers. The MCOORD vector contains 
the number of the last coordinate assigned. 
The MVD table is composed of 128 entries, 
with each entry containing a pointer to the 
dictionary entry for the variable or con- 
stant to which the corresponding coordinate 
number is assigned or to the information 
table entry for the base variable to which 
the corresponding coordinate is assigned. 
The coordinate number assigned to a vari- 
able or constant is recorded in the byte-C 
usage field of the dictionary entry for 
that variable or constant. 

Subroutine lEKKOS does not assign coor- 
dinates to or record usage information for 
unique constants encountered in text after 
coordinate number 60 has been assigned and 
unique variables encountered in text after 
coordinate number 80 has been assigned. If 
subroutine lEKKOS encounters a new constant 
after coordinate 60 has been assigned or a 
new variable after coordinate 80 has been 
assigned, it records a zero in the byte-C 
usage field of its associated dictionary 
entry. Phase 20 optimization deals only 
with those constants and variables that 
have been assigned coordinate numbers 
greater than or equal to 2 and less than or 
equal to 8 0. 

Processing Common Entries in the Informa- 
ti on T ^ble; The STALL-IEKGST subroutine 
processes common entries in the information 
table. It computes the displacements of 
variables and arrays from the start of the 
common block that contains them and calcu- 
lates the total size in bytes of each com- 
mon block. Subroutine STALL-IEKGST records 
the displacements in the dictionary entries 
for the variables and the block size in the 
common table entry for the name of the com- 
mon block. The displacements are used 
later to assign relative addresses to com- 
mon variables. The block size is used by 
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phase 25 to generate a control section for 
the common block (see Appendix A: "Common 
Table"). The STALL-IEKGST subroutine also 
places a pointer to the common table entry 
for the block name in the dictionary entry 
for each variable or array in that common 
block. 

Processing Equivale nce Entri es in the 
Information Table; Subroutine STALL-IEKGST 
gathers additional information about equi- 
valence groups and the variables in them. 
It computes a group head^ and the displace- 
ment) of each variable in the group from 
this head. It records this information in 
the common table entries for the group and 
for the variables, respectively (see Appen- 
dix A: "Common Table"). Subroutine STALL- 
IEKGST identifies and flags in their dic- 
tionary entries variables and arrays put 
into common via the EQUIVALENCE statement. 
It also checks the variables and arrays for 
errors to verify that the associated common 
block has not been improperly extended 
because of the EQUIVALENCE declaration. If 
a common block is legitimately enlarged by 
an equivalence operation, the STALL-IEKGST 
subroutine recomputes the size of the com- 
mon block and enters the size into the com- 
mon table entry for the name of the common 
block. 

If the name of a variable or array 
appears in more than one equivalence group, 
subroutine STALL-IEKGST recognizes the com- 
bination of groups and modifies the dic- 
tionary entries for the variables to indic- 
ate the equivalence operations. The STALL- 
IEKGST subroutine checks arrays that appear 
in more than one equivalence group to veri- 
fy that conflicting relationships have not 
been established for the array elements. 

During the processing of both common and 
equivalence information, a check is made to 
ensure that variables and arrays fall on 
boundaries appropriate to their defined 
types. If a variable or array is improper- 
ly aligned, subroutine STALL-IEKGST places 
an entry in the error table for processing 
by phase 30. 



CONSTRUCTING A CROSS REFERENCE 



If the XREF option is selected, a two- 
part cross reference is constructed and 
written on the SYSPRINT data set immediate- 
ly following the source listing. The first 
part of the cross reference is a list of 



all symbols used by the program and the 
ISNs of the statements in which each symbol 
appears. The symbols are written in alpha- 
betic order and grouped by character 
length, first one-character symbols in 
alphabetic order, then two-character sym- 
bols in alphabetic order, etc. The second 
part of the cross reference is a sequential 
list of the statement numbers used on the 
program each followed by the ISN of the 
statement in which the statement number is 
defined and also by a list of the ISNs of 
statements that refer to the statement 
number. 

XREF processing occurs during phase 10 
and in a small separate overlay segment 
between phases 10 and 15. This segment, 
XREF-IEKXRF, is called only if the XREF 
option is selected. 



Phase 10 Preparation for XREF Processing 



If the XREF option is chosen, phase 10 
subroutines LABTLU-IEKCLT and CSORN-IEKCCR 
perform additional processing for statement 
numbers and symbols. Also, phase 10 sub- 
routine lEKXRS, which is not used unless 
the XREF option is chosen, is called. 

The LABTLU-IEKCLT subroutine fills the 
adcon table, which is used as an XREF buff- 
er, with XREF entries for statement number 
definitions and statement number 
references. The format of an XREF entry 
for statement numbers and symbols is : 



^The head of an equivalence group is that 
variable in the group from which all other 
variables or arrays in the group can be 
addressed by a positive displacement. 



< u bytes > 

r T 1 

I Pointer to nex^ j | 

JXREF entry* j ISN | 

L X. J 

♦ Relative to the beginning of the buffer. 



Each time the buffer is full, the 
LABTLU-IEKCLT subroutine calls lEKXRS to 
write the buffer on SYSUT2. (The contents 
of SYSUT2 is later read in by subroutine 
XREF-IEKXRF and processed to produce a 
cross reference. ) A count of the number of 
times the buffer is written out is kept in 
the communication table NPTR (2,20). Each 
time it finishes writing the buJEfer on SYS- 
UT2, subroutine lEKXRS returns control to 
the LABTLU-IEKCLT subroutine. 

Subroutine LABTLU-IEKCLT uses parts of 
the dictionary entries for statement num- 
bers as pointers to keep track of its 
processing. It also adds a word (word 9) 
to each statement number dictionary entry 
to be used as a sequence chain field so 



28 



that subroutine XREF-IEKXRF can create a 
sequential list of statement ntimbers used 
in the proojram. 



The words used by the LABTLU-IEKCLT sub- 
routine in dictionary entries for statement 
numbers are : 



Word 5 - A pointer to the most recent 
statement number entry in the 
adcon table (XREF buffer) if the 
statement number reference being 
processed by subroutine LABTLU- 
IEKCLT is not a definition of a 
statement number. Word 5 is not 
used for statement number entries 
that correspond to definitions of 
statement numbers. 

Word 6 - Bytes 1 and 2 — The number of 
times the XREF buffer has been 
written on SYSUT2 at the time the 
statement number entry is proc- 
essed by subroutine LABTLU-IEKCLT. 

Bytes 3 and U — A pointer to the 
first XREF buffer entry for the 
statement number. 

Word 7 - Contains an ISN if the reference 
is to a definition of a statement 
number; contains -1 if the state- 
ment number has been previously 
defined. 

Word 9 - Statement number sequence chain 
field. 



The CSORN-IEKCCR subroutine processes 
symbols for XREF much the same way as sub- 
routine LABTLU-IEKCLT processes statement 
numbers. However, for symbols, no 
processing is required for definitions and 
there is no sequencing. 

The CSORN-IEKCCR subroutine adds one 
word to the dictionary entries for 
variables making a total of ten words in 
each entry. Word 10 for a variable entry 
is used in the same way as word 6 for a 
statement number entry. The first half of 
word 10 indicates the number of times the 
buffer has been written on SYSUT2 at the 
time the variable entry is processed by 
subroutine CSORN-IEKCCR. The second half 
of word 10 contains a pointer to the first 
XREF buffer entry for the symbol. The 
first half of word 8 is used as a pointer 
to the last (most recent) XREF buffer entry 
for the symbol. 

Subroutine lEKXRS is also used during 
symbol processing to write the XREF buffer 
out on SYSUT2 whenever the buffer becomes 
full. 



XREF Processing 



If the XREF option is selected, the FSD 
calls the XREF-IEKXRF subroutine after the 
completion of subroutine STALL-IEKGST 
processing and before phase 15. The XREF- 
IEKXRF subroutine is a separate overlay 
segment that overlays phase 10 and is over- 
laid by phase 15. 

Subroutine XREF-IEKXRF reads from SYSUT2 
all buffers that were written out by lEKXRS 
during svibroutine LABTLU-IEKCLT and subrou- 
tine CSORN-IEKCCR processing. It then sets 
up linkage between buffers for the symbol 
or statement number to create one sequen- 
tial chain of ISNs and writes out the sym- 
bol or statement number with its ISNs on 
SYSPRINT. This process continues until all 
symbols and statement numbers with their 
ISNs are written on SYSPRINT. Control is 
then returned to the FSD that calls phase 
15. 



PHASE 15 



Before phase 15 gains control, phase 10 
has read the source statements, built the 
information table, and restructured the 
source statements into operator-operand 
pairs. When given control, phase 15 trans- 
lates the text of arithmetic expressions, 
gathers information about branches and 
variables, converts phase 10 data text to a 
new text format, assigns relative addresses 
to constants and variables, and generates 
address constants when needed, to serve as 
address references. Thus, phase 15 modi- 
fies and adds to the information table and 
translates phase 10 normal and data text to 
their phase 15 formats. 

Phase 15 is divided into two overlay 
segments, PHAZ15, and CORAL. Chart 05 
shows the overall logic of the phase. 
Table 9 is a directory of all the subrou- 
tines used by phase 15. 

PHAZ15 translates and reorders the text 
entries for arithmetic expressions from the 
operator-operand format of phase 10 to a 
four-part format suitable for phase 20 
processing. The new order permits phase 25 
to generate machine instructions in the 
correct sequence. PHAZ15 blocks the text 
and collects information describing the 
blocks. The information, needed during 
phase 20 optimization, includes tables on 
branching locations and on constant and 
variable usage. 

CORAL, the second overlay segment of 
phase 15, performs a number of functions. 
It first converts phase 10 data text to a 
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form more easily evaluated by subroutine 
DATOUT-IEKTDT. CORAL then assigns relative 
addresses to all variables, constants, and 
arrays. During one phase of relative 
address assignment, CORAL rechains phase 15 
data text in order to simplify the genera- 
tion of text card images by subroutine 
DATOUT-IEKTDT. CORAL also assigns address 
constants, when needed, to serve as address 
references for all operands. 



PHAZ15 PROCESSING 



The functions of PHAZ15 are text block- 
ing, arithmetic translation, information 
gathering, and reordering of the statement 
number chain. Information gathering occurs 
only if optimization (either intermediate 
or complete) has been selected; it takes 
place concurrently with text blocking and 
arithmetic translation during the same scan 
of intermediate text. Reordering of the 
statement number chain occurs after PHAZ15 
has completed the blocking, arithmetic 
translation, and information gathering, 

PHAZ15 divides intermediate text into 
blocks for convenience in obtaining infor- 
mation from the text. Each block begins 
with a statement number definition and ends 
with the text entry just preceding the next 
statement number definition. An attempt is 
made to limit blocks to less than 80 text 
items as an aid to register routines in 
phase 20, PHAZ15 records information 
describing a text block in a statement 
number text entry and in an information 
table statement number entry. 

During the same scan of text in which 
blocking occurs,, PHAZ15 translates arith- 
metic expressions. The conversion is from 
the operation-operand pairs of phase 10 to 
a four-part format (phase 15 text). The 
new format follows the sequence in which 
algebraic operations are performed. In 
general, phase 15 text is in the same order 
in which phase 25 will generate machine 
instructions.^ PHAZ15 copies, tjnchanged 
into the text area, phase 10 text that does 
not require arithmetic translation or other 
special handling. 

During the building of phase 15 text for 
a given block (if optimization has been 
selected), PHAZ15 constructs tables of 
information on the use of constants and 
variables in that text block. It stores 
information on variables and constants that 
are used within a block, and variables that 
are defined within a block. If complete 



optimization has been selected, PHAZ15 also 
gathers information on variables not first 
used and then defined. The foregoing usage 
information is recorded in the statement 
number text for each block for later use by 
phase 20. 

Concurrently with text blocking, arith- 
metic translation, and gathering of 
constant/variable usage information, PHAZ15 
discovers branching text entries and 
records the branching or connection infor- 
mation. This information, consisting ini- 
tially of a table of branches from each 
text block (forward connections), is stored 
in a special array. Branching (connection) 
information is used during phase 20 
optimization. 

After PHAZ15 has completed the previous- 
ly mentioned processing , it reorders the 
statement number chain of the information 
table. The original sequence of statement 
numbers, as phase 10 recorded them, was in 
the order of their occurrence in source 
statements as either definitions^ or 
operands. Phase 15 reorders the statement 
numbers in the same sequence as they 
appeared as definitions in the source pro- 
gram. The new sequencing is established to 
facilitate phase 20 processing. 

Last, PHAZ15 acquires a table of back- 
ward connection information consisting of 
branches into each statement nxjmber or text 
block. PHAZ15 derives this information 
from the forward connection information it 
previously obtained. Thus, connection 
information is of two types, forward and 
backward. PHAZ15 records a table of 
branches from each text block and a table 
of branches into each text block. Connec- 
tion information of both types is used dur- 
ing phase 20 optimization. 

Charts 06, 07, and 08 depict the flow of 
control during PHAZ15 execution. Table 10 
lists the COMMON areas of phase 15. 



Text_ Blocking 



During its scan and conversion of phase 
10 text, PHAZ15 sections the module into 
text blocks, which are the basic units upon 
which the optimization and register assign- 
ment processes of phase 20 operate, A text 
block is a series of text entries that 
begins with the text entry for a statement 
number and ends with the text entry that 
immediately precedes the text entry for the 



^If optimization is selected, phase 20 may 
further manipulate the phase 15 text. 



^A statement nvunber occurs as a definition 
when that statement number appears to the 
left of a source statement. 
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next statement number. (The statement 
number may be either programmer defined or 
compiler generated. ) When PHAZ15 encoun- 
ters a statement number definition (i.e., 
the phase 10 text entry for a statement 
number) , it begins a text block. It does 
this by constructing a statement number 
text entry (refer to Appendix B, "Phase 15 
Intermediate Text Modifications"). PHAZ15 
also places a pointer to the statement 
number text entry into the statement number 
entry (information table) for the asso- 
ciated statement number. 

PHAZ15 resumes its scan and converts the 
phase 10 text entries following the state- 
ment number definition to their phase 15 
formats. After each phase 15 text entry is 
formed and chained into text, PHAZ15 places 
a pointer to that text entry into the 
BLKEND field of the previously constructed 
statement number text entry. This field 
is, thereby, continually updated to point 
to the last phase 15 text entry. 

When the next statement number defini- 
tion is encountered, PHAZ15 begins the next 
text block in the previously described 
manner. A pointer to the text entry that 
ends the preceding block has already been 
recorded in the BLKEND field of the state- 
ment number text entry that begins that 
block. Thus, the boundaries of a text 
block are recorded in two places: the 
beginning of the block is recorded in the 
associated statement number entry (informa- 
tion table) ; the end of the block is re- 
corded in the BLKEND field of the asso- 
ciated statement number text entry. All 
text blocks in the module are identified in 
this manner. 

Note: For each ENTRY statement in the 
source module, phase 10 generates a state- 
ment number text entry and places it into 
text preceding the text for the ENTRY 
statement. Phase 10 also ensures that the 
statement following an ENTRY statement has 
a statement number; if a statement n\imber 



is not provided by the programmer, phase 10 
generates one. Thus, the text entries for 
each ENTRY statement form a separate text 
block, which is referred to as an entry 
block. 

Figure 3 illustrates the concept of text 
blocking. In the illustration, two text 
blocks are shown: one beginning with 
statement number 10; the other with state- 
ment number 20. The statement number entry 
for statement number 10 contains a pointer 
to the statement number text entry for 
statement number 10, which contains a 
pointer to the text entry that immediately 
precedes the statement number text entry 
for statement n\imber 20. Similar pointers 
exist for the text block starting with 
statement number 20. 



Arithmetic Translation 



Arithmetic translation is the reordering 
of arithmetic expressions in phase 10 text 
format to agree with the sequence in which 
algebraic operations are performed. Arith- 
metic expressions may exist in IF, CALL, 
and ASSIGN statements and input/output 
data-lists, as well as in arithmetic state- 
ments and statement functions. 

When PHAZ15 detects a primary adjective 
code for a statement that needs arithmetic 
translation, it passes control to the 
arithmetic translator (ALTRAN-IEKJAL) . If 
the phase 10 text for the statement does 
not require any type of special handling, 
ALTRAN-IEKJAL reorders it into a series of 
phase 15 text entries that reflect the 
sequence in which arithmetic operations are 
to be carried out. During the reordering 
process, ALTRAN-IEKJAL calls various sup- 
porting routines that perform checking and 
resolution (e.g., the resolution of opera- 
tions involving operands of different 
modes) functions. 
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Statement Number Entry for 
Statement Number 10 



Statement Number Entry for 
Stotement Number 20 



10 



20 



* LDF is the mnemonic for the statement number operator 



Figure 3. Text Blocking 



PHASE 15 TEXT 



LDF* 



10 



LDF* 



20 



LDF* 



Throughout the reordering process, 
ALTRAN-IEKJAL is checking for text that 
requires special handling before it can be 
placed into the phase 15 text area. [Spe- 
cial handling is required for complex 
expressions, terms involving unary minuses 
(e.g., A=-B) , subscript expressions, state- 
ment function references, etc.] If 
special text processing is required, 
ALTRAN-IEKJAL calls one or more subroutines 
to perform the required processing. 

During reordering and, if required, spe- 
cial handling, subroutine GENER-IEKLGN is 
called to format the phase 15 text entries 
and to place them into the text area. 



REORDERING ARITHMETIC EXPRESSIONS; The 
reordering of arithmetic expressions is 
done by means of a pushdown table. This 
table is a last-in, first-out list. After 
the table is initialized (i.e., the first 
operator-operand pair of an arithmetic 
expression is placed into the table) , the 
arithmetic translator (ALTRAN-IEKJAL) com- 
pares the operator of the next operator- 
operand pair (term) in text with the opera- 
tor of the pair at the top of the pushdown 
table. As a result of each comparison, 
either a term is transferred from phase 10 
text to the table, or an operator and two 
operands (triplet) are brought from the 
table to the phase 15 text area, eliminat- 
ing the top term in the pushdown table. 

The comparison made to determine whether 
a term is to be placed into the pushdown 
table or whether a triplet is to be taken 
from the pushdown table is always between 



the operator of a term in phase 10 text and 
the operator of the top term in the table. 
Each comparison is made on the basis of 
relative forcing strength . A forcing 
strength is a value assigned to an operator 
that determines when that operator and its 
associated operands are to be placed in 
phase 15 text. The relative values of 
forcing strengths reflect the hierarchy of 
algebraic operations. The forcing 
strengths for the various operators appear 
in Table 2. 



When the arithmetic translator (ALTRAN- 
IEKJAL) encounters the first operator- 
operand pair (phase 10 text entry) of a 
statement, the pushdown table is empty. 
Since the translator cannot yet make a com- 
parison between text entry and table ele- 
ment, it enters the first text entry in the 
top position of the table. The translator 
then compares the forcing strength of the 
operator of the next text entry with that 
of the table element. If the strength of 
the text operator is greater than that of 
the top (and only) table element, the text 
entry (operator-operand pair) becomes the 
top element of the table. The original top 
element is effectively "pushed down" to the 
next lower position. In Figure 4, the 
number-1 section of the drawing shows the 
pushdown table at this time. 



The operator of the next text entry 
(operator C — operand C at section 2) is 
compared with the top table element (opera- 
tor B — operand B at section 1) in a similar 
manner. 
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Table 2. Operators and Forcing Strengths 
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When a comparison of forcing strengths 
indicates that the strength of the text 
operator (operator C, section 2), is less 
than or equal to that of the top table ele- 
ment (operator B), the table element is 
said to be "forced. " The forced operator 
(operator B) is placed in the new phase-15 
text entry (section 3 of the illustration) 
with its operand (operand B) and the 
operand of the next lower table entry 
(operand A). Note that subroutine ALTRAN- 
lEKJAL has generated a new operand t (see 
section 3) called a "temporary," A tem- 
porary is a compiler- generated operand in 
which a preliminary result may be held dur- 
ing object-module execution,*- With operator 
B, operand B, and operand A (a triplet) 
removed from the pushdown table, the pre- 
viously entered operator- operand pair 
(operator A, section 1) now becomes the top 
element of the table (section 4), The 
ALTRAN- lEKJAL subroutine assigns the pre- 
viously generated temporary t as the 
operand of this pair. This temporary 
represents the previous operation (operator 
B — operand A — operand B), 

Comparisons and text-to-table exchanges 
continue, a higher strength text operator 



"pushing" a phase 10 text entry into the 
table and a lower strength text operator 
"forcing" the top table operator and its 
operands (triplet) from the table. In each 
case, the forced table items become the new 
phase 15 text entry. An exception to the 
general rule is a left parenthesis, which 
has the highest forcing strength. Opera- 
tors following the left parenthesis can be 
forced from the table only by a right 
parenthesis, although the intervening 
operators (between the parentheses) are of 
lower forcing value. When the translator 
reaches an end mark in text, its forcing 
strength of 1 forces all remaining elements 
from the table. 



SPECIAL PROCESS ING OF ARITHMETIC EXPRES- 
SIONS ; As Stated before, arithmetic trans- 
lation involves reordering a group of phase 
10 text entries to produce a new group of 
phase 15 text entries representing the same 
source statement. Certain types of 
entries, however, need special handling 
(for example, subscripts and functions). 
When it has been determined that special 
handling is needed, control is passed to 
one or more other subroutines (see Chart 
07) that perform the desired processing. 

The following expressions and terms need 
special handling before they are placed in 
phase 15 text: complex expressions, terms 
involving a unary minus, terms involving 
exponentiation, commutative expressions, 
subscript expressions, subroutine or func- 
tion subprogram references, statement func- 
tion references, and expressions involved 
in logical IF statements. 



Complex Expressions; A complex expression 
is converted into two expressions, a real 
expression and an imaginary one. For real 
elements in the expression, complex tem- 
poraries are generated with zero in the 
imaginary part and the real element in the 
real part. For example, the complex 
expression B + C + 25. is treated as: 



B 
real 



C 
real 



25. 
real 



^A given temporary may be eliminated by 
phase 20 during optimization. 



B 
imag 



C 
imag 



0. 
imag 
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1 . Text in Pushdown Table 



2. Phase 10 Text Entries 



Top Element 



Operator 


Operand 


OpB 
Op A 


Oprnd B 
Oprnd A 



4. New Top Element of Pushdown 



Op A 



Operator 


Operand 


Op C 
Op D 


Oprnd C 
Oprnd D 



3. New Phase 15 Text Entry 



Current phase 10 text entry 
Next phase 10 text entry 



Op B 


t 


Oprnd A 


Oprnd B 



Operator 



Operand 1 



Operand 2 



Operand 3 



NOTE: A phase 15 text entry having an arithmetic operator may be envisioned as 

operand 1 = operand 2 - operator - operand 3, where the equal sign is Implied. 

Figure 4, Text Reordering via the Pushdown Table 



An expression is not treated as complex 
if the "result" operand (left of the equal 
sign in the source statement) is real. In 
this case, the translator places only the 
real part of the expression in phase 15 
text. But if a complex multiplication, 
division, or exponentiation is involved in 
the expression, the real and imaginary 
parts will appear in phase 15 text, but 
only the real part of the result will be 
used at execution time. 

T erms Containing a Unary Minus ; In terms 
that contain unary minuses, the unary 
minuses are combined with additive opera- 
tors (+, -) to reduce the number of opera- 
tors. This combining, done by subroutine 
UN/^Y-IEKKUN, may result in reversed opera- 
tors or operands or both in phase 15 text. 
For example, -(B-C) becomes C-B, and A+(-B) 
becomes A-B, This process reduces the 
number of machine instructions that phase 
25 must generate. 

Operations Involving Powers ; Several kinds 
of special handling are provided by subrou- 
tine UNARY- lEKKUN for operations involving 
powers. Multiplications by powers of two 
are converted to left shift operations. A 
constant integer power of two raised to a 
constant integer power is converted to the 
equivalent left shift operation. Last, a 
constant or variable raised to a constant 
integer power is converted to a series of 
multiplications (and a division operation 
into 1, if the power is negative). This 
conversion is a function of the level of 
optimization selected. This handling 
requires less execution time than using an 
exponentiation subroutine. 

Commutative Operations : If an operation is 
commutative (either operand can be operated 
upon, such as in addinor or multiplying) , the 



two operands are reordered to agree with 
their absolute locations in the dictionary. 

Subscripts ! Subroutines SUBMULT-IEKKSM and 
SUBADD-IEKKSA perform subscript processing. 
Subscripted items are processed one at a 
time throughout the subscript. If the sub- 
script itself is an expression, it is first 
processed via the translator. Text entries 
are then generated to multiply the sub- 
script variable by the dimension factor and 
length. Each subscript item is handled in 
a similar manner. When all subscript items 
have been processed, phase 15 text entries 
are generated to add all subscript values 
together to produce a single subscript 
value. 

In general, during compilation, con- 
stants in subscript expressions are com- 
bined, and their composite value is placed 
in the displacement field of the phase 15 
text entry for the subscript item (see 
Appendix B, "Phase 15/Phase 20 Intermediate 
Text Modifications"), Phase 25 uses the 
value in the displacement field to gener- 
ate, in the resultant object instructions, 
the displacement for referring to the ele- 
ments in the array. This combining of con- 
stants reduces the number of instructions 
needed during execution to compute the sub- 
script value. 

Expressio ns Referr ing t o In-Line Routines 
or Subprogram s: Expressions containing 
references to in-line routines or subpro- 
grams are processed by the following sub- 
routines: FUNDRY-IEKJFU, BLTNFN-IEKJBF, 
and DFUNCT-IEKJDF. 

Arguments that are expressions are 
reduced by the translator to a single tem- 
porary, which is used as the argument. If 
an argument is a subscripted variable, sub- 
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script processing (previously discussed) 
reduces the subscript to a single sub- 
scripted item. Either subroutine DFUNCT- 
lEKJDF (for references to library routines) 
or subroutine BLTNFN-IEKJBF (for references 
to in-line routines) then conducts a series 
of tests on the argument and performs the 
processing determined by the results of the 
tests. 



I variables into a parameter list. (Load 
address items are not required if none of 
the arguments are subscripted variables.) 
A text entry having a library function 
operator is generated. This entry points 
to the dictionary entry for the function. 
The text representation of the argument 
list is then generated and placed into the 
phase 15 text chain. 



If a function is not external and is in 
the function table (lEKLFT) (see Appendix 
A, "Function Table"), it is determined if 
the required routine is in-line. If the 
function is in-line and its mode (or the 
mode of its arguments) is not as expected, 
it is assumed that the function is extern- 
al. If there are no error conditions, sub- 
routine BLTNFN-IEKJBF either generates text 
or substitutes a special operator (such as 
those for ABS or FLOAT) in the phase 15 
text so that phase 25 can later expand the 
function. Phase 15 provides some in-line 
routines itself.^ Instead of placing a spe- 
cial operator in text, phase 15 inserts a 
regular operator, such as the operator for 
AND or STORE. 



If the mode of arguments in a library 
function is not as expected, another test 
is performed. The test determines whether 
or not a previous reference was made 
correctly for these arguments. If the pre- 
vious reference was as expected, it is 
assumed that an error exists, otherwise, 
the function is assumed to be external. 



If a function is assumed to be external 
(either used in an EXTERNAL statement or 

I does not appear in the function table) , 
text is generated to load the addresses of 
any arguments that are subscripted 

I variables into a parameter list. (If none 
of the arguments are subscripted variables, 
the load address items are not required, ) 
A text entry for a subroutine or a function 
call is then generated. The operator of 
the text entry is for an external function 
or subroutine reference. The entry points 
to the dictionary entry for the name. The 
text representation of the argximent list is 
then generated and placed into the phase 15 
text chain. 



If a function is in the function table, 
but does not represent an in-line routine, 
text is generated to load the addresses of 
any arguments that are subscripted 



Parameter List Optimization : Subr out i ne 
DFUNCT-IEKJDF performs parameter list opti- 
mization. If two or more parameter lists 
are identical, all but one can be eli- 
minated. Likely candidates for optimiza- 
tion are those parameter lists with (1) the 
same number of parameters and (2) the same 
nonzero parameters. When two such lists 
are found, individual parameters are com- 
pared to determine whether the lists are 
actually identical or merely of the same 
format. 



To make the comparison easier, the Pa- 
rameter List Optimization Table is formed. 
Its format is: 



I Pointer 
I to Next 
I Entry of 
Pointer JLike 
to NADCON I Format 
Table I in This 
Entry j Table 



^BLTNFN-IEKJBF expands the following func- 
tions: TBIT, LAND, LOR, LXOR, SNGL, REAL, 
AIMAG, DCMPLX, DCONJG, and CONJG. 



I I Number of 

] Number of j Nonzero 
I Parameters} Parameters 
I in List jin List 

|. 4 4- 

j 1 byte I 1 byte | 1 byte ) 1 byte | 

L X J. X J 



For each unique parameter list, an entry is 
made in the table describing the number of 
parameters in the list, the number of non 
zero parameters in the list, a pointer to 
the adcon table (see Appendix A: "NADCON 
Table") and a pointer to the next parameter 
list optimization table entry that contains 
a like parameter list format, but unlike 
individual parameters. When a new parame- 
ter list is generated, the parameter list 
optimization table is scanned for a 
possible identical list. If one is found, 
the parameters in the new list are compared 
with the parameters in the old list. If 
the lists are identical, a pointer to the 
old list is used as the new list's pointer. 
If the lists are not identical, an entry 
for the new list is made in the table and 
chained to the last like (in format) entry. 
For example : 
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handling, the statement IF{A. AND.B. AND. C) 
GO TO 500 will produce (at object time) a 
branch to the next statement if A is false, 
because B and C need not be tested. Thus, 
only a minimum number of operands will be 
tested. Without anchor-point handling of 
the expression during compilation, all 
operands would be tested at object time. 
Similar special handling occurs for text 
containing logical ORs. 



When a primary adjective code for a 
logical IF statement or an end-of-DO IF is 
placed in the pushdown table, a scan of 
phase 10 text determines whether or not the 
associated statement can receive anchor- 
point handling. The statement can receive 
anchor-point handling if two conditions are 
met. There must not be a mixture of ANDs 
and ORs in the statement. A logical ex- 
pression, if it is in parentheses, must not 
be negated by the NOT operator. If these 
two conditions are not met, special hand- 
ling of the logical expression does not 
occur. 



Parameter list optimization is limited 
to (1) 100 entries in the parameter list 
optimization table or (2) 255 entries in 
the adcon table. No further parameter list 
optimization is attempted if either limit 
is exceeded. 



Gathering Constant/Va riable_Usage 
Information 



Expressions Containing Statement Function 
References ; For expressions containing 
statement function references, the argu- 
ments of the statement function text are 
reduced to single operands (if necessary). 
These arguments and their mode are stored 
in an argument save table (NARGSV), which 
serves as a dictionary for the statement 
function skeleton pointed to by the dic- 
tionary entry for the statement function 
name. The argument save table is used in 
conjunction with the usual pushdown proce- 
dure to generate phase 15 text items for 
the statement function reference. When the 
translator encounters an operand that is a 
dummy argument, the actual argument corre- 
sponding to the dummy is picked up from the 
argument save table and replaces the dummy 
arqument. 



Logical Expressions; Subroutines ALTRAN- 
lEKJAL, ANDOR-IEKJAN, and RELOPS-IEKKRE 
perform a special process, called anchor 
point, on logical expressions containing 
relational operators, ANDs, ORs, and NOTs, 
so that, at object time, unnecessary 
logical tests are eliminated. With anchor- 
point "optimization, " only the minimum 
number of object-time logical tests are 
made before a branch or fall-through 
occurs. For example, with anchor-point 



During the conversion of the phase 10 
text entries that follow the beginning of a 
text block (i.e., the text entries that 
follow a statement niimber definition) to 
phase 15 format, the PHAZ15 subroutine 
MATE-IEKLMA gathers usage information for 
the variables and constants in that block. 
This information is required during the 
processing of the optimizer path through 
phase 20 (see "Phase 20"). If optimizer 
processing is not selected, this informa- 
tion is not compiled. Subroutine MATE- 
IEKLMA records the usage information in 
three fields (MVS, MVF, and MVX) , each 128 
bits long, of the statement number text 
entry for the block (see Appendix B, "Phase 
15 Intermediate Text Modifications"). The 
MVS field indicates which variables are 
defined (i.e., appear in the operand 1 
position of a text entry) within the text 
of the block. The MVF field indicates 
which variables, constants, and base 
variables (see "Adcon and Base Variable 
Assignment" under "CORAL Processing") are 
used (i.e., appear in either the operand 2 
or operand 3 position of a text entry) 
within the text of the block. The MVX 
field indicates which variables are defined 
but not first used (not busy-on-entry) 
within the text of the block. The MVX 
information is gathered for the second 
level of optimization only. 
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Subroutine MATE-IEKLMA records the usage 
information for a variable or constant at a 
specific bit location within the three 
fields. (Base variables are processed dur- 
ing CORAL processing. ) The bit location at 
which the usage information is recorded is 
determined from the coordinate assigned to 
the variable or constant by subroutine 
lEKKOS. 



Gathering Forward-Connection_ Information 



An integral part of the processing of 
PHAZ15 is the gathering of forward- 
connection information, which indicates the 
specific text blocks that pass control to 
other specified text blocks. Forward- 
connection information is used during phase 
20 optimization. 



After a phase 15 text entry has been 
formed, subroutine MATE-IEKLMA is given 
control to determine and record the usage 
information for the text entry. It 
examines the text entry operands in the 
order: operand 2, operand 3, operand 1. 
If operand 2 has not been assigned a coor- 
dinate, subroutine MATE-IEKLMA assigns it 
the next coordinate, enters the coordinate 
number into the dictionary entry for the 
operand, and places a pointer to that dic- 
tionary entry into the MVD table entry 
associated with the assigned coordinate 
number. After MATE-IEKLMA has assigned the 
coordinate, or if the operand was previous- 
ly assigned a coordinate, it records the 
usage information for the operand. The 
operand's associated coordinate bit in the 
MVF field (of the statement number text 
entry for the .block containing the text 
entry under consideration) is set to on, 
indicating that the operand is used in the 
block. Subroutine MATE-IEKLMA executes a 
similar procedure to process operand 3 of 
the text entry. 

If operand 1 of the text entry has not 
been assigned a coordinate, the MATE-IEKLMA 
subroutine assigns the next coordinate to 
it and records the following usage informa- 
tion for operand 1: 

• Its associated coordinate bit in the 
MVX field is set to on only if the 
associated coordinate bit in the MVF 
field is not on. (If the associated 
MVF bit is on, operand 1 of the text 
entry was previously used in the block 
and, therefore, is not not busy-on- 
entry. ) 

• Its associated coordinate bit in the 
MVS field is set to on, indicating that 
it is defined within the block. 

This process is repeated for all of the 
phase 15 text entries that are formed fol- 
lowing the construction of a statement 
number text entry and preceding the con- 
struction of the next statement n\unber text 
entry. When the next statement number text 
entry is constructed, all of the usage 
information for the preceding block has 
been recorded in the statement number text 
entry that begins that block. The same 
procedure is followed to gather the usage 
information for the next text block. 



Forward-connection information is 
recorded in a table called RMAJOR. Each 
RMAJOR entry is a pointer to the statement 
number entry associated with a statement 
number that is the object of a branch or a 
fall-through. Because each statement numb- 
er entry contains a pointer to the text 
block beginning with its associated state- 
ment number (see "Text Blocking"), each 
RMAJOR entry points indirectly to a text 
block. 



For each new text block, PHAZ15 places a 
pointer to the next available entry in 
RMAJOR into the forward- connection field of 
the associated statement number entry (see 
Appendix A, "Statement Number/Array 
Table"). Thus, the statement number entry 
associated with the text block points to 
the first entry in RMAJOR in which the 
forward-connection information for that 
block is to be recorded. 



After starting a text block, PHAZ15 con- 
verts the phase 10 text following the 
statement number definition to phase 15 
text. As each phase 15 text entry is 
formed, it is analyzed to determine whether 
it is a GO TO or compiler generated branch. 
If it is either, a pointer to the statement 
number entry for each statement number to 
which a branch may be made as a result of 
the execution of the GO TO or generated 
branch is recorded in the next available 
entry in RMAJOR. (If two or more branches 
to the same statement number appear in the 
block only one entry is made in RMAJOR for 
the statement number to which a branch is 
to be made. ) 



When PHAZ15 encounters the next state- 
ment number definition, it starts a new 
block. If the new block is an entry block, 
PHAZ15 saves a pointer to its associated 
statement number entry for subsequent use 
and processes the text for the block. 



If the new block is neither an entry 
block nor an entry point (i.e., a block 
immediately following an entry block) , 
PHAZ15 records the fall-through connection 
information (if any) for the previous 
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block. If the previous block is terminated 
by an unconditional branch, it does not 
fall-through to the new block. If the pre- 
vious block can fall-through to the new 
block, PHAZ15 records a pointer to the 
statement number entry for the new block in 
the next location of RMAJOR. It then flags 
this as the last forward connection for the 
previous block. 



is shown. In the illustration, it is 
assumed that: 



• The block started by statement number 
10 may branch to the blocks started by 
statement numbers 30 and 40 and will 
fall-through to the block started by 
statement niimber 20 if neither of the 
branches is executed. 



If the new block is an entry point 
(i.€i., a block immediately following an 
entry block) , PHAZ15 records the fall- 
through connection (if any) for the pre- 
vious non-entry block. It does this in the 
manner described in the previous paragraph. 
It then records the forward-connection 
information for all intervening entry 
blocks (i.e., entry blocks between the pre- 
vious non-entry block and the new block). 
(PHAZ15 has saved pointers to the statement 
number entries for all intervening entry 
blocks. ) Each such entry block passes con- 
trol directly to the new block and there- 
fore has only one forward connection. To 
record the forward connection information 
for the intervening entry blocks, PHAZ15 
places a pointer to the next available 
entry in RMAJOR into the forward connection 
field of the statement number entry for the 
first intervening entry block. In this 
RMAJOR entry, PHAZ15 records a pointer to 
the statement number entry for the new 
block. It flags this entry as the last, 
and only, RMAJOR entry for the entry block. 
PHAZ15 repeats this procedure for the 
remaining intervening entry blocks (if 
any). PHAZ15 then proceeds to process the 
new text block. 



When all the connection information for 
a block has been gathered, each Rl^JOR 
entry for the block, the first of which is 
pointed to by the statement number entry 
for the block and the last of which is 
flagged as such, points indirectly to a 
block to which that block may pass control. 



Figure 5 illustrates the end result of 
gathering forward- connect ion information 
for sample text blocks. Only the forward- 
connection information for the blocks 
beginning with statement numbers 10 and 20 



The block started by statement number 
20 may branch to the blocks started by 
statement numbers 40 and 50 and will 
fa 11- through to the block started by 
statement number 30 if neither of the 
branches is executed. 



Reordering the Sta tement _Number Chain 



After text blocking, arithmetic transla- 
tion, and if complete optimization has been 
specified, the gathering of constant/ 
variable usage information, been completed, 
subroutine PHAZ15-IEKJA reorders the state- 
ment niimber chain of the information table 
(see Appendix A, "Information Table"), The 
original sequence of the entries in this 
chain, as recorded by phase 10, was in the 
order of the occurrence of their associated 
statement numbers as either definitions or 
operands. The new sequence of the entries 
after reordering is made according to the 
occurrence of their associated statement 
numbers as definitions only. 



Although the actual reordering takes 
place after the scan of the phase 10 text, 
preparation for it takes place during the 
scan. As each statement number definition 
is encountered, a pointer to the related 
statement number entry is recorded. Thus,. 
during the course of processing, a table of 
pointers to statement number entries, which 
reflects the sequence in which statement 
niimbers are defined in the module, is 
built. The order of the entries in this 
table also reflects the sequence of the 
text blocks of the module. 
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PHASE 15 TEXT 
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Figure 5. Forward-Connection Information 



After the scan, subroutine PHAZ15-IEKJA 
uses this table to reorder the statement 
number entries. It places the first table 
pointer into the appropriate field of the 
communication table (see Appendix A, "Com- 
munication Table"); it places the second 
table pointer into the chain field of the 
statement number entry that is pointed to 
by the pointer in the communication table; 
it places the third table pointer into the 
chain field of the statement number entry 
that is pointed to by the chain field of 
the statement number entry that is pointed 
to by the pointer in the communication 
table; etc. When subroutine PHAZ15-IEKJA 
has performed this process for all pointers 
in the table, the entries in the statement 
number chain are arranged in the sequence 
in which their associated statement numbers 
are defined in the module. The nev/ order 
of the chain also reflects the sequence of 
the text blocks of the module. 



Gathering Backward-Conne ct i on Information 



After the statement number chain has 
been reordered, and if optimization has 
been specified, subroutine PHAZ15-IEKJA 



gathers backward-connection information. 
This information indicates the specified 
text blocks that receive control from spe- 
cific other text blocks. Backward- 
connection information is used extensively 
throughout phase 20 optimization. 

Subroutine PHAZ15-IEKJA uses the reor- 
dered statement number chain and the infor- 
mation in the forward connection table 
(RMAJOR) to determine the backward connec- 
tions. It records backward-connection 
information in a table called CMAJOR in 
subroutine C1520-IEKJA2. Each CMAJOR entry 
made by subroutine PHAZ15-IEKJA for a par- 
ticular text block (block I) is a pointer 
to the statement number entry for a block 
from which block I may receive control. 
Because each statement number entry con- 
tains a pointer to its associated text 
block (see "Text Blocking"), each CMAJOR 
entry for block I points indirectly to a 
block from which block I may receive 
control. 

Subroutine PHAZ15-IEKJA gathers 
backward-connection information for the 
text blocks according to the order of the 
statement number chain. It first deter- 
mines and records the backward-connections 
for the text block associated with the ini- 
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tial entry in the statement number chain, 
then gathers the backward-connection infor- 
mation for the block associated with the 
second entry in the chain; etc. 



For each text block, subroutine PHAZ15- 
lEKJA initially records a pointer to the 
next available entry in CMAJOR in the 
backward-connection field (JLEAD) of the 
associated statement number entry (see 
Appendix A, "Statement Number/Array 
Table"), Thus, the statement number entry 
points to the first entry in CMAJOR in 
which the backward-connection information 
for the block is to be recorded. 



Then, to determine the backward- 
connection information for the block (block 
I), subroutine PHAZ15-IEKJA obtains, in 
turn, each entry in the statement number 
chain, (The entries are obtained in the 
sequence in which they are chained, ) After 
the PHAZ15-IEKJA subroutine has obtained an 
entry, it picks up the forward-connection 
field (ILEAD) of that entry. This field 
points to the initial RMAJOR entry for the 
text block associated with the obtained 
statement number entry. ( Note ; RMAJOR 
entries for a block indicate the blocks to 
which that block may pass control, ) Sub- 
routine PHAZ15-IEKJA searches all RMAJOR 
entries for the block associated with the 
obtained entry for a pointer to the state- 
ment number entry for block I, If such a 
pointer exists, the text block associated 
with the obtained statement number entry 
may pass control to block I, Therefore, 
block I may receive control from that block 
and subroutine PHAZ15-IEKJA records a 
pointer to its associated statement number 
entry in the next available entry in CMAJOR. 
Subroutine PHAZ15-IEKJA repeats this 
procedure for each entry in the statement 
n\amber chain. Thus, it searches all RMAJOR 
entries for pointers to the statement 
number entry for block I and records in 
CMAJOR a pointer to the statement number 



entry for each text block from which block 
I may receive control. The PHAZ15-IEKJA 
subroutine flags the last entry in CMAJOR 
for block I, When the statement number 
chain has been completely searched, subrou- 
tine PHAZ15-IEKJA has gathered all the 
backward-connection information for block 
I, Each entry that the PHAZ15-IEKJA sub- 
routine has made for block I, the first of 
which is pointed to by the statement number 
entry for block I and the last of which is 
flagged, points indirectly to a block from 
which block I may receive control. 



Svibroutine PHAZ15-IEKJA gathers the 
backward-connection information for all 
blocks in the aforementioned manner. When 
all of this information has been gathered, 
control is returned to the FSD, which calls 
CORAL, the second segment of phase 15, 



Figure 6 illustrates the end result of 
the gathering of backward-connection infor- 
mation for sample text blocks. Only the 
backward-connections for the blocks begin- 
ning with statement numbers 40 and 50 are 
shown. In the illustration, it is assumed 
that: 

• The block started by statement number 
40 may receive control from the execu- 
tion of branch instructions that reside 
in the blocks started by statement num- 
bers 10 and 20 and that it may receive 
control as a result of a fall-through 
from the block started by statement 
number 30, 



The block started by statement number 
50 may receive control from the execu- 
tion of a branch instruction that 
resides in the block started by state- 
ment number 20 and that it may receive 
control as a result of a fall-through 
from the block started by statement 
number 40, 
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CORAL PROCESSING 

CORAL, the second segment of phase 15, 
performs the following functions: 

• Data text conversion 

• Relative address assignment 

• Data text rechaining 

• Namelist statement processing 

• Define file text processing 

• Initial value assignment 

• Adcon table space reservation 



CORAL consists of a main subroutine, 
CORAL- lEKGCR, which controls the flow of 
space allocation for variables, constants, 
and any adcons necessary for local 
variables, COMMON, EQUIVALENCE, and EXTER- 
NAL references. Embedded in subroutine 
CORAL-IEKGCR are the routines that process 
constants, local variables, and external 
references. The CORAL-IEKGCR subroutine 
calls other routines in phase 15 to 



accomplish various functions. These rou- 
tines are: 



• lEKGCZ, which keeps track of space 
being allocated; generates adcons 
needed for address computation in the 
object module; rechains data text in 
the sequence of variable assignment; 
generates adcons necessary for COMMONi 
EQUIVALENCE, and EXTERNAL references; 
and sets up error table entries to be 
used by phase 30 if errors occur. 

• NDATA-IEKGDA, which processes phase 10 
data text. 

• EQVAR-IEKGEV, which handles COMMON and 
EQUIVALENCE space allocation. 

• NLIST-IEKTNL, which processes namelist 
text. 

• DFILE-IEKTDF, which processes define 
file text. 

• DATOUT-IEKTDT, which processes data 
text. 

Chart 09 shows the overall logic flow ol 
CORAL. 
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Translation of Data Text 



The first section of CORAL, subroutine 
NDATA-IEKGDA, translates data text entries 
from their phase 10 format to a form more 
easily processed by another CORAL subrou- 
tine, DATOUT-IEKTDT. Each phase 10 data 
text entry (except for initial housekeeping 
entries) contains a pointer to a variable 
or constant in the information table. Each 
variable in the series of entries is to be 
assigned to a constant appearing in another 
entry. Placed in separate entries, vari- 
able and constant appear to be unrelated. 
In each phase 15 data text entry, after 
translation, each related variable and con- 
stant are paired (they appear in adjacent 
fields of the same entry) . 



r T T T 1 

I Indicator I Chain j PI Field |P2 Field j 
f 1 1 ^ ^ 

I I I pointer | pointer | 
I I I to A in I to in I 
I I jdictionary I dictionary I 
^ + + + ^ 

I I [pointer | pointer | 
I I I to B in I to in I 
I I I dictionary jdictionary I 
L J. X JL . J 



In this case, each variable and its speci- 
fied constant value appear in adjacent 
fields of the same phase 15 text entry. 
For the detailed format of the phase 15 
data text entry and the use of the special 
fields not discussed, see Appendix B, 
"Phase 15/20 Intermediate Text 
Modification". 



The following example shows how a series 
of phase 10 data text entries are trans- 
lated by the NDATA-IEKGDA subroutine to 
yield a smaller number of phase 15 text 
entries, with each related constant and 
variable paired. Assume a statement 
appearing in the source module as DATA 
A, B/2+0/. The resulting phase 10 text 
entries appear as follows (ignoring the 
chain, mode, and type fields, and the ini- 
tial housekeeping entry) : 



r T 1 

I Adjective | | 
1 Code for: j Pointer j 
|. 1 ^ 

1 1 Pointer to A | 
I 1 in dictionary j 
|.___ + ^ 

1 , 1 Pointer to B ] 
1 j in dictionary | 
|. + ^ 

1 / 1 2 1 

L _ L_ 4 


r — — — r~ — — 1 

1 * 1 Pointer to | 
I 1 in dictionary j 

L J._ _J 


r T 1 

1 / 1 1 

L i J 



Note that the variables A and B and the 
constant value appear in separate text 
entries. The NDATA-IEKGDA subroutine tran- 
slation of the above phase 10 entries 
(ignoring the contents of the indicator and 
chain fields, and two optional fields 
needed for special cases) appears as 
follows : 



Relative Address Assignment 



The chief function of CORAL is to assign 
relative addresses to the operands (con- 
stants and variables) of the source module. 
The addresses indicate the locations, rela- 
tive to zero, at which the operands will 
reside in the object module resulting from 
the compilation. The relative address 
assigned to an operand consists of an 
address constant and a displacement. These 
two elements, when added together, form the 
relative address of the operand. The 
address constant for an operand is the base 
address value used to refer to that operand 
in main storage. Address constants ate 
recorded in the adcon table (NADCON) and 
are the elements to which the relocation 
factor is added to relocate the object 
module for execution. The displacement for 
an operand indicates the number of bytes 
that the operand is displaced from its 
associated address constant. Displacements 
are in the range of to 4 095 bytes. The 
relative address assigned to an operand is 
recorded in the information table entry for 
that operand in the form of : 

1. A numeric displacement from its asso- 
ciated address constant. 

2, A pointer to an information table 
entry that contains a pointer to the 
associated address constant in the 
adcon table. 

Relative addresses are assigned through 
use of a location counter. This counter is 
I continually updated by the size (in bytes) 
of the operand to which an address is 
assigned. The value of the location count- 
er is used to: 



^2 



• Compute the displacement to be assigned 
to the next operand. 



• Determine when the next address con- 
stant is to be established. (If the 
displacement reaches a value in excess 
of 4095, a new address constant is 
established. ) 

CORAL assigns addresses to source module 
operands in the following order: 

• Constants. 

• Variables. 

• Arrays . 

• Equivalenced variables and arrays. 

• COMMON variables and arrays, including 
variables and arrays made common using 
the EQUIVALENCE statement. 



The manner in which addresses are assigned 
to each of these operand types is described 
in the following paragraphs. Because con- 
stants and variables are processed in the 
same manner, they are described together. 



constants andVariables : Subroutine CORAL- 
lEKGCR first assigns relative addresses to 
the constants of the module. As each con- 
stant is assigned a relative address, sub- 
routine CORAL- lEKGCR calls the FSD subrou- 
tine, lEKTLOAD, to place the constant in 
the object module in the form of TXT 
records. Addresses are then assigned to 
variables. (In the subsequent discussion, 
constants and variables are referred to 
collectively as operands.) The first 
operand is assigned a displacement of zero 
plus the length of the save area, parameter 
list, and branch table. Operands that are 
assigned locations within the first U096 
bytes of the range of base register 13 are 
not explicitly assigned an address con- 
stant. Such operands use the base address 
value loaded into reserved register 13 as 
their address constant. The displacement 
is recorded ;in the information table entry 
for that operand. The location counter is 
then updated by the size in bytes of the 
operand. 

The next operand is assigned a displace- 
ment equal to the current value of the 
location counter minus the base address 
value in register 13. The displacement is 
recorded in the information table entry for 
that operand. The location counter is then 
updated, and the value of the displacement 
is tested to see whether or not it exceeds 
4095. If it does not, the next operand is 
processed as described above. 



If sufficient operands exist to cause 
I the displacement to achieve a value in 
excess of 4095, the first address constant 
is established. The value of this address 
constant equals the location counter value 
that caused its establishment. This 
address constant becomes the current 
address constant and is saved for subse- 
quently assigned relative addresses. The 
displacement value is then reset to zero 
and the next operand is considered. 

After the first address constant is 
established, it is used as the address con- 
stant portion of the relative addresses 
assigned to subsequent operands. 

When the value of the displacement again 
reaches a value in excess of 4095, another 
address constant is established. Its value 
is equal to the current address constant 
plus the displacement that caused the esta- 
blishment of the new address constant. 
This new address constant then becomes cur- 
rent and is used as the address constant 
I for subsequent operands. The displacement 
is then reset to zero and the next operand 
is processed. This overall process is 
repeated until all operands (constants and 
variables) are processed. Source module 
arrays are then considered for relative 
address assignment. 

Arrays ; Subroutine CORAL-IEKGCR then 
assigns to each array of the source module 
that is not in COMMON a relative address 
that is less than (by the span of the 
array) the relative address at which the 
array will reside in the object module. 
(The concept of span is discussed in Appen- 
dix F, ) The actual relative address at 
which an array will reside in the object 
module is derived from the sum of address 
constant and displacement that are current 
at the time the array is considered for 
relative address assignment. The array 
span is subtracted from the relative 
address to facilitate subscript 
calculations. 

Subroutine CORAL-IEKGCR subtracts the 
span in one of two ways. If the span is 
less than the current displacement, it sub- 
tracts the span from that displacement, and 
assigns the result as the displacement por- 
tion of the relative address for the array. 
In this case, the address constant assigned 
to the array is the current address con- 
stant. If the span is greater than the 
current displacement, the CORAL-IEKGCR sub- 
routine subtracts the span from the sum of 
the current address constant and displace- 
ment. The result of this operation is a 
new address constant, which does not become 
the current address constant. Subroutine 
CORAL-IEKGCR assigns the new address con- 
stant and a displacement of zero to the 
array. It then adds the total size of the 
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array to the location counter, obtains the 
next array, and tests the value of the dis- 
placement. If the value of the displace- 
ment does not exceed 4095, the CORAL-IEKGCR 
subroutine does not take any additional 
action before it processes the next array. 
If the displacement value exceeds 409 5, the 
CORiUli-IEKGCR subroutine establishes a new 
address constant, resets the displacement 
value and processes the next array. After 
all arrays have relative addresses, subrou- 
tine CORAL-IEKGCR calls subroutine EQVAR- 
lEKGEV to assign address to equivalence 
variables and arrays that are not in 
COMMON . 

Equivalence Variables and Arrays Not in 
COMMON ; In assigning relative addresses to 
equivalence variables and arrays, subrou- 
tine EQVAR-IEKGEV attempts to minimize the 
number of required address constants by 
using, if possible, previously established 
address constants as the base addresses for 
equivalence elements. Subroutine EQVAR- 
IEKGEV processes equivalence information on 
a group-by-group basis, and assigns a rela- 
tive address, in turn, to each element of 
the group. Prior to processing, subroutine 
EQVAR-IEKGEV determines the base value for 
the group. The base value is the relative 
address of the head^ of the group. The 
base value equals the sum of the current 
address constant and displacement (location 
counter value) . After the EQVAR-IEKGEV 
subroutine has determined the base value, 
it obtains the first (or next) element of 
the group and computes its relative 
address. The relative address for an ele- 
ment equals the sum of the base value for 
the group and the displacement of the ele- 
ment. The displacement for an element is 
the number of bytes that the element is 
displaced from the head of the group (see 
"COMMON and EQUIVALENCE Processing"). The 
EQVAR-IEKGEV subroutine then compares the 
computed relative address to the previously 
established address constants. If an 
address constant is such that the dif- 
ference between the computed relative 
address and the address constant is less 
than 4095, the EQVAR-IEKGEV subroutine 
assigns that address constant to the equi- 
valence element under consideration. The 
displacement assigned in this case is the 
difference between the computed relative 
address of the element and the address con- 
stant. Subroutine EQVAR-IEKGEV then pro- 
cesses the next element of the group. 

If the desired address constant does not 
exist, subroutine EQVAR-IEKGEV establishes 
a new address constant and assigns it to 



^The head of an equivalence group is the 
variable in the group from which all other 
variables or arrays in the group can be 
addressed by a positive displacement. 



the element. The value of the new address 
constant is the relative address of the 
element. The EQVAR-IEKGEV subroutine then 
assigns the element a displacement of zero, 
and processes the next element of the 
group. When all elements of the group are 
processed, subroutine EQVAR-IEKGEV computes 
the base value for the next group, if any. 
This base value is equal to the base value 
of the group just processed plus the size 
of that group. The next group is then 
processed. 



COMMON Variables a.nd Arrays: Subroutine 
EQVAR-IEKGEV considers each COMMON block of 
the source module, in turn, for relative 
address assignment. For each COMMON block, 
subroutine EQVAR-IEKGEV assigns relative 
addresses to (1) the variables and arrays 
of that block, and (2) the variables and 
arrays equivalenced into that COMMON block. 
(The processing of variables and arrays 
equivalenced into COMMON is described in a 
later paragraph. ) 

Because COMMON blocks are considered 
separate control sections, the EQVAR-IEKGEV 
subroutine assigns each COMMON block of the 
source module a relocatable origin of zero. 
It achieves the origin of zero by assigning 
to the first element of a COMMON block a 
relative address consisting of an address 
constant and a displacement whose sum is 
zero. For example, both the address con- 
stant and the displacement for the first 
element in a block can be zero. Also, the 
address constant can be -16 and the 
displacement +16. Note that the address 
constant in the latter case is negative. 
Negative address constants are permitted, 
and may be a by-product of the assignment 
of addresses to COMMON variables and 
arrays. They evolve from the manner in 
which the relative addresses are assigned 
to arrays. A relative address assigned to 
an array is equal to its actual relative 
address minus the span of that array. The 
actual relative address of each array in a 
common block is equal to the displacement 
computed for it during COMMON and EQUIVA- 
LENCE processing. From the displacement of 
each array in the COMMON block under consi- 
deration, subroutine EQVAR-IEKGEV subtracts 
the span of that array. The result then 
replaces the previously computed displace- 
ment for the array. If the result of one 
or more of these computations yields a 
negative value, the EQVAR-IEKGEV subroutine 
uses the most negative as the initial 
address constant for the COMMON block. It 
then assigns each element (variable or 
array) in the COMMON block a relative 
address. This address consists of the 
negative address constant and a displace- 
ment equal to the absolute value of the 
address constant plus the displacement of 
the element. 
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If the computations that subtract spans 
from displacements do not yield a negative 
value, subroutine EQVAR-IEKGEV establishes 
an address constant with a value of zero as 
the initial address constant for the COMMON 
block. It then assigns each element in the 
block a relative address consisting of the 
address constant (with zero value) and a 
displacement equal to the displacement of 
the element. 



If at any time the displacement to be 
assigned to an element exceeds U095, the 
EQVAR-IEKGEV subroutine establishes a new 
address constant. This address constant 
then becomes the current address constant 
and is saved for inclusion in subsequently 
assigned addresses. After the new address 
constant is established, the relative 
address assigned to each subsequent element 
consists of the current address constant 
and a displacement equal to the displace- 
ment of that; element minus the value of the 
current address constant. After the entire 
common block is processed, variables and 
arrays that are equivalenced into that com- 
mon block are assigned relative addresses. 



Vari abl es _and Arrays_Eguivalenced into ,Com: 
mon: Subroutine EQVAR-IEKGEV processes 
variables and arrays that are equivalenced 
into common in much the same manner as 
those that are equivalenced, but not into 
common. However, in this case, the base 
value for the group is zero. Only those 
address constants established for the com- 
mon block into which the variables and 
arrays are equivalenced are acceptable as 
address constants for those variables and 
arrays. 



Rechaininq Data Text 



During the assignment of relative 
addresses to variables, subroutine lEKGCZ 
rechains the data text entries. Their pre- 
vious chaining (set by phase 10) was 
according to their sequence in the source 
program. The lEKGCZ subroutine now chains 
the data text entries according to the 
sequence of relative addresses it assigns 
to variables. Thus, data text entries are 
now chained in the same relative sequence 
in which the variables will appear in the 
object module. This sequence simplifies 
the generation of text card images by phase 
25. 



DEFINE_FILE^ St atement Processing 



If the source module contains DEFINE 
FILE statements, subroutine DFILE-IEKTDF 
converts phase 10 define file text to 
object-time parameters. These parameters 
provide IHCFDIOSE with the information 
required to implement direct access READ, 
WRITE, and FIND statements. 

A parameter entry is made for each unit 
specified in a DEFINE FILE statement. This 
entry contains the unit number, the rela- 
tive address of the number of records, a 
character (*L', 'E', or 'U') indicating the 
type of formatting to be used, the relative 
address of the maximum record size, an 
indicator for the size (four bytes or two 
bytes) of the associated variable, and the 
relative address of the associated 
variable. 



Adcon and Base. Variable Assignment : As 
CORAL establishes a new address constant 
and enters it into the adcon table, it also 
places an entry in the information table. 
This special entry, called an "adcon vari- 
able, " points to the new address constant. 
All operands: that have been assigned rela- 
tive addresses will have pointers to the 
adcon variable for their address constant. 
The adcon variables generated for operands 
are assigned coordinates, via the MCOORD 
vector and the MVD table. Coordinates 81 
through 128 are reserved for base 
variables; however, some base variables may 
be assigned coordinates less than 81 if 
less than 8 coordinates are assigned dur- 
ing the gathering of variable and constant 
usage information (see PHAZ15, "Gathering 
Constant/ Variable Usage Information"). 
Having been assigned coordinates, the adcon 
variables are now called base variables . 
Only those operands receiving coordinate 
assignments are available for full register 
assignment during phase 20. 



Subroutine DFILE-IEKTDF places the 
parameter entries along with their relative 
addresses into TXT records. It also places 
the relative address of the first define 
file entry into the communication table for 
later use by phase 25. 



NAMELIST_Statement_Processing 



If the source module contains READ/WRITE 
statements using NAMELIST statements, sub- 
routine NLIST-IEKTNL converts phase 10 
namelist text to object-time namelist dic- 
tionaries. The object-time namelist dic- 
tionaries provide IHCFCOMH with the infor- 
mation required to implement READ/WRITE 
statements using namelists (see Appendix A, 
"Namelist Dictionaries"). The dictionary 
developed for each list in a NAMELIST sta- 
tement contains the following: 
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• An entry for the namelist name. 

• Entries for the variables and arrays 
associated with the namelist name. 

• An end mark of zeros terminating the 
list. 

Each entry for a variable contains the 
name, mode (e.g., integer*2 or real+U), and 
relative address of the variable. Both the 
address and the mode are obtained from the 
dictionary entry for the variable. 

Each entry for an array contains the 
name of the array, the mode of its ele- 
ments, the relative address of its first 
element, and the information needed to 
locate a particular element of the array. 
Subroutine NLIST-IEKTNL obtains the forego- 
ing information from the information table. 

The NLIST-IEKTNL subroutine places the 
entries of the namelist dictionary along 
with their relative addresses into TXT 
records. It also places the relative 
address of the beginning of the namelist 
dictionary into the address constant for 
the namelist name. 



Initial Value Assignment 



lEKGCR scans the operands of the informa- 
tion table to detect any of these 
references: call-by-name variables, names 
of library routines, namelist names, and 
external references. The byte-A and byte-B 
usage fields of each information table 
entry informs subroutine CORAL-IEKGCR 
whether or not a particular reference 
belongs to one of these categories. For 
each special reference that the CORAL- 
IEKGCR subroutine detects, subroutine 
lEKGCZ calls subroutine lEKTLOAD to place 
the needed address constants in the 
reserved spaces of the object module. 



Crea ting Relocation Dictionary Entries 



The relocation dictionary is composed of 
entries for the address constants of the 
object module. One relocation dictionary 
entry (an RLD record) is constructed by 
subroutine CORAL-IEKGCR for each address it 
encounters. If the address constant is for 
an external symbol, the RLD record identi- 
fies the address constant by indicating: 

• The control section to which the 
address constant belongs. 

• The location of the address constant 
within the control section. 



CORAL assigns the initial values speci- 
fied for variables and arrays in phase 15 
data text in the following manner: 

1. The relative address of the variable 
or array to be assigned an initial 
value (s) is obtained and placed into 
the address field of a TXT record, 

2. Each constant (one per variable) that 
has been specified as an initial value 
for the variable or array is then 
obtained and entered into a TXT re- 
cord. (A number of TXT records may be 
required if an array is being 
processed. ) 

Such action effectively assigns the ini- 
tial value, because the relative address of 
the initial value has been set to equal the 
relative address of its associated variable 
or array element. 



• The symbol in the external symbol dic- 
tionary whose value is to be used in 
the computation of the address 
constant. 

If the address constant is for a local 
symbol (i.e., a symbol that is located in 
the same control section as the address 
constant) , the RLD record identifies the 
address constant by indicating the control 
section to which the address constant 
belongs and its location within that 
section. 

For a more detailed discussion of the 
use and format of an RLD record, refer to 
the publication IBM Svstem/3 60 Operating 
System: Linkage Editor, Program Logic 
Manual , Form Y28-6610. 



Creating External Symbol_ Dictionary Entries 



Reserving Space in the Adcon Tab le 



After relative address assignment is 
completed, subroutine CORAL-IEKGCR calls 
the lEKTLOAD subroutine (via lEKGCZ) to 
place an adcon in the object module for 
special references. Subroutine CORAL- 



The external symbol dictionary contains 
entries for external symbols that are 
defined or referred to within the module. 
An external symbol is one that is defined 
in one module and referred to in another. 
One external symbol dictionary entry (an 
ESD record) is constructed by subroutine 
lEKGCZ for each external symbol it encoun- 
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ters. The entry identifies the symbol by 
indicating its type and location within the 
module. The ESD records constructed by 
subroutine lEKGCZ are: 

• ESD-0 — >■ This is a section definition 
record and an entry point definition 
record for the source module being 
compiled. 

• ESD-2 — This record is generated for 
an external subprogram name. 

• ESD-5 -- This record is a section 
definition record for a common block 
(either named or blank). 

For a more complete discussion of the 
use and the format of these records, refer 
to the publication IBM §YStem/360_Op era ting 

S ys tem; Linkage Editor^ Pr ogram Logic 

Manual. 



PHASE 20 



The primary function of phase 20 is to 
produce a more efficient object module 
(perform optimization) . However, even if 
the applications programmer has specified 
no optimization, phase 20 assigns registers 
for use during execution of the object 
module. 

For a given compilation, the applica- 
tions programmer may specify OPT=0 (no 
optimization), or either of the following 
levels of optimization: 0PT=1 or 0PT=2. 
Thus, the functions performed by phase 20 
depend on the optimization specified for 
the compilation. 

• If no optimization (OPT=0) has been 
specified, phase 20 assigns to interme- 
diate text entry operands the registers 
they will require during object module 
execution (this is called basjc regis- 
te r assignment ). As part of this func- 
tion, phase 20 also provides informa- 
tion about the operands needed by phase 
25 to generate machine instructions. 
Both functions are implemented in a 
single, block- by-block, top-to-bottom 
(i.e., according to the order of the 
statement number chain), pass over the 
phase 15 text output. The end result 
of this processing is that the register 
and status fields of the phase 15 text 
entries are filled in with the informa- 
tion required by phase 25 to convert 
the text entries to machine language 
form (see Appendix B, "Phase 20 Inter- 
mediate Text Modifications"). Basic 
register assignment does not take full 
advantage of the available general and 
floating-point registers, and it does 



not specify the generation of machine 
instructions that keep operand values 
in registers (wherever possible) for 
use in subsequent operations involving 
them. 

• If the 0PT=1 level of optimization has 
been specified, two processes are car- 
ried out: 

1. The first process, called full 
register assignment , performs the 
same two functions as basic regis- 
ter assignment. However, full 
register assignment takes greater 
advantage of available registers 
and provides information that 
enables machine instructions to be 
generated that keep operand values 
in registers for subsequent opera- 
tions. An attempt is also made to 
keep the most frequently used 
operands in registers throughout 
the execution of the object 
module. Full register assignment 
requires a number of passes over 
the phase 15 text. The basic unit 
operated upon is the text block 
(see Phase 15, "Text Blocking"), 
The end result of full register 
assignment, like that of basic 
register assignment, is that the 
register and status fields of the 
phase 15 text entries are filled 
in with the information required 
by phase 25. 

2. The second process, called branch 
optimization, generates RX- format 
branch instructions in place of 
RR-format branch instructions 
wherever possible. The use of 
RX-format branches eliminates the 
need for an instruction to load 
the branch address into a general 
register. However, branch optimi- 
zation first requires that the 
sizes of all text blocks in the 
module be determined so that the 
branch address can be found. 

• If the 0PT=2 level of optimization has 
been specified, optimization is per- 
formed on a "loop- by-loop" basis. 
Therefore, before processing can be 
initiated, phase 20 must determine the 
structure of the source module in terms 
of the loops within it and the rela- 
tionships (nesting) among the loops. 
Then phase 20 determines the order in 
which loops are processed, beginning 
with the innermost (most frequently 
executed) loop and proceeding outward. 
The second level of optimization 
involves three general procedures: 

1. The first, called te xt optimiza- 
tion, eliminates unnecessary text 
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entries from the loop being 
processed. For example, redundant 
text entries are removed and, 
wherever possible, text entries 
are moved to outer loops, where 
they will be executed less often. 

The second procedure is full reg- 
ister assignment, which is essen- 
tially the same as in the first 
level of optimization, but is more 
effective, because it is done on a 
loop- by-loop basis. 

The final procedure is branching 
optimization, which is the same as 
in the 0PT=1 path. 



CONTROL FLOW 



In phase 20, control flow may take one 
of three possible paths, depending on the 
level of optimization chosen (see Chart 
10). Phase 20 consists of a control rou- 
tine (LPSEL-IEKPLS) and six routine groups. 
(Table 12 is a directory of the subroutines 
used by these six groups. In addition. 
Table 13 contains the list of utility rou- 
tines called by the subroutines in the 
various groups.) The control routine con- 
trols execution of the phase. All paths 
begin and end with the control routine. 
The first group of routines performs basic 
register assignment. This group is 
executed only in the control path for non- 
optimized processing. The second group 
perforins full register assignment. Control 
passes through this group in the paths for 
both levels of optimization. The third 
group of routines performs branch optimiza- 
tion and is also used in the paths for both 
levels of optimization. The fourth group 
determines the structure of the source 
module and is used only in the path for 
OPT=2 optimization. The fifth group per- 
forms loop selection and again is only 
executed in OPT=2 optimization. The final 
group performs text optimization and is 
used only in 0PT=2 optimization. 

The control routine governs the sequence 
of processing through phase 20. The proc- 
essing sequence to be followed is deter- 
mined from the optimization level specified 
by the FORTRAN programmer. If no optimiza- 
tion is specified, the basic register 
assignment routines are brought into play. 
The unit of processing in this path is the 
text block. When all blocks are processed, 
the control routine passes control to the 
FSD, which calls phase 25. 

When 0PT=1 optimization is specified, 
the control routine passes the entire 
module to the full register assignment rou- 



tines and then to the routine that computes 
the size of each text block and sets up the 
displacements required for branching opti- 
mization. Control is then passed to the 
FSD. 

When the control path for 0PT=2 optimi- 
zation is selected, the unit of processing 
is a loop, rather than a block. In this 
case, the control routines initially pass 
control to the routines of phase 20 that 
determine the structure of the module. 
When the structure is determined, control 
is passed to the loop selection routines, 
to select the first (innermost) loop to be 
processed. The control routines then pass 
control to the text-optimization routines 
to process the loop. When text optimiza- 
tion for a loop is completed, the control 
routine marks each block in the loop as 
completed. This action is taken to ensure 
that the blocks are not reprocessed when a 
subsequent (outer) loop is processed. The 
control routine again passes control to the 
loop selection routines to select the next 
loop for text optimization. This process 
is repeated until text optimization has 
processed each loop in the module. (The 
entire module is the last loop. ) 

After text optimization has processed 
the entire module, the control routine 
removes the block-completed marks and con- 
trol is passed to the loop selection rou- 
tines to reselect the first loop. Control 
is then passed to the full register assign- 
ment routines. When full register assign- 
ment for the loop is complete, the control 
routine marks each block in the loop as 
completed and passes control to the loop 
selection routines to select the next loop. 
This process is repeated for each loop in 
the module. (The entire module is the last 
loop. ) When all loops are processed, the 
control routine passes control to the rou- 
tine that computes the size of each text 
block and sets up the displacements 
required for branching optimization. Con- 
trol is then passed to the FSD. 



REGISTER ASSIGNMENT 



Two types of register assignment can be 
performed by phase 20: basic and full. 
Before describing either type, the concept 
of status, which is integrally connected 
with both types of assignment, is 
discussed. 

Each text entry has associated operand 
and base address status information that is 
set up by phase 20 in the status field of 
that text entry (see Appendix B, "Phase 20 
Intermediate Text Modification"). The sta- 
tus information for an operand or base 
address indicates such things as whether or 



48 



not it is in la register and whether or not 
it is to be retained in a register for sub- 
sequent use; this information indicates to 
phase 25 the machine instructions that must 
be generated for text entries. 

The relationship of status to phase 25 
processing id illustrated in the following 
example. Consider a phase 15 text entry of 
the form A = B + C. To evaluate the text 
entry, the operands B and C must be added 
and then stored into A. However, a number 
of machine instruction sequences could be 
used to evaluate the expression. If 
operand B is in a register, the result can 
be achieved by performing an RX- format add 
of C to the register containing B, provided 
that the base address of C is in a regis- 
ter. (If the base address of C is not in a 
register, it must be. loaded before the add 
takes place. ) The result can then be 
stored into A, again, provided that the 
base address of A is in a register. 

If both B and C are in registers, the 
result can be evaluated by executing an 
RR- format add; instruction. The result can 
then be stored into A, Thus, for phase 2 5 
to generate code for the text entry, it 
must have thel status of operands and base 
addresses of the text entry. 

The following facts about status should 
be kept in mind throughout the discussions 
of basic and full register assignment: 

1. Phase 20: indicates to phase 25 when it 
is to generate code that loads 
operands and base addresses into reg- 
isters, whether or not it is to gener- 
ate code that retains operands and 
base addresses in registers, and 
whether or not operand 1 is to be 
stored, 

2. Phase 20 notes the operands and base 
addresses that are retained in regis- 
ters and: are available for subsequent 
use. 



Basic Register Assignment — OPT =0 



Basic register assignment involves two 
functions: assigning registers to the 
operands of the phase 15 text entries and 
indicating the machine instructions to be 
generated for: the text entries. In per- 
forming these functions, basic register 
assignment does not use all of the avail- 
able registers, and it restricts the 
assignment of; those that it does use to 
special types! of items (i,e., operands and 
base addresses). The registers assigned 
during basic register assignment and the 
item(s) to which each is assigned are out- 
lined in Table 3. 



Basic register assignment essentially 
treats System/360 as though it had a single 
branch register, a single base register, 
and a single accumulator. Thus, operands 
that are branch addresses are assigned the 
branch register, base addresses are 
assigned the base register, and arithmetic 
operations are performed using a single 
accumulator, (The accumulator used depends 
upon the mode of the operands to be 
operated upon. ) 



The fact that basic register assignment 
uses a single accumulator and a single base 
register is the key to understanding how 
text entries having an arithmetic operator 
are processed. To evaluate the arithmetic 
interaction of two operands using a single 
accumulator, one of the operands must be in 
the accumulator. The specified operation 
can then be performed by using an RX-format 
instruction. The result of the operation 
is formed in the accumulator and is avail- 
able for subsequent use. Note that in 
operations of this type, neither of the 
interacting operands remains in a register. 



Table 3. Item Types and Registers 

Assigned in Basic Register 
Assignment 



r T 

[Register | Item Type 
^ 4 

1 Floating-Point 




[General Purpose] 
0-1 



7 

in 



15 



Arithmetic text entry 
operands that are real. 

Imaginary part of the 
result of a complex 
function. 



Arithmetic text entry 
operands that are inte- 
ger, or logical operands. 

Branch addresses and 
selected logical 
operands. 

Operands that represent 
index values. 

Base addresses. 

1. Used for computed GO 
TO operations. 

2. Logical result of 
comparison opera- 
tions. 

Used for computed GO TO 
operations. 
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Applying this concept to the processing 
of text entries that are arithmetic in 
nature, consider that a phase 15 text entry 
representing the expression A = B + C is 
the first of the source module. For this 
text entry to be evaluated using a single 
accumulator and base register, basic regis- 
ter assignment must tell phase 25 to gener- 
ate machine code that: 



(operand 1) of the preceding text entry. 
The second is specified for text entries in 
which either operand 2 or operand 3 corres- 
ponds to the result operand. If operand 3 
corresponds to the result operand, the two 
operands exchange roles, except for divi- 
sion. In the case of division, operand 3 
is always in main storage. 



• Loads the base address of B into the 
base register. 

• Loads B into the accumulator. 

• Loads the base address of C into the 
base register. (This instruction is 
not necessary if C is assigned the same 
base address as B. ) 

• Adds C to the accumulator (RX- format 
add). 

• Loads the base address of A into the 
base register (if necessary). 

• Stores the accumulated result in A. 



If this coding sequence were executed, 
two items would remain in registers: the 
last base address loaded and the accumu- 
lated result. These items are available 
for subsequent use. 



Now consider that a text entry of the 
form D = A + F immediately follows the 
above text entry. In this case, A, which 
corresponds to the result operand of the 
previous text entry, is in the accumulator. 
Thus, for this text entry, basic register 
assignment specifies code that: 

• Loads the base address of F into the 
base register. (If the base address of 
F corresponds to the last loaded base 
address, this instruction is not 
necessary. ) 

• Adds F to the accumulator (RX-format 
add). 

• Loads the base address of D into the 
base register (if necessary). 

• Stores the acc\imulated result in D. 



The foregoing coding sequences are the 
basic ones specified by basic register 
assignment for arithmetic operations. The 
first is specified for text entries in 
which neither operand 2 nor operand 3 (see 
Table 3) corresponds to the result operand 



If both operands 2 and 3 correspond to 
the result operand of the previous text 
entry, an RR-format operation is specified 
to evaluate the interactions of the 
operands. 



In the actual process of basic register 
assignment, a single pass is made over the 
phase 15 text output. The basic unit 
operated upon is the text block. As the 
processing of each block is completed, the 
next block is processed. When all blocks 
are processed, control is returned to the 
FSD. 



Text blocks are processed in a top-to- 
bottom manner, beginning with the first 
text entry in the block. When all text 
entries in a block are processed, the next 
text block is processed similarly. 

For any text entry, the machine code to 
be generated is first specified by setting 
up the status field of the text entry. 
Registers are then assigned to the operands 
and base addresses by filling in the 
register fields of the text entry. 



Status se tting: Subroutine SSTAT-IEKRSS 
sets the operand and base address status 
information for a text entry in the follow- 
ing order: operand 2, operand 2 base 
address, operand 3, operand 3 base address, 
operand 1, and operand 1 base address. 



To set the status of operand 2, subrou- 
tine SSTAT-IEKRSS determines the relation- 
ship of that operand to the result operand 
(operand 1) of the previous text entry. If 
operand 2 is the same as the result 
operand, the SSTAT-IEKRSS subroutine sets 
the status of operand 2 to indicate that it 
is in a register and, therefore, need not 
be loaded; otherwise, it sets the status to 
indicate that it is in main storage. Sub- 
routine SSTAT-IEKRSS uses a similar proce- 
dure to set the status of operand 3. 



To set the status of the base address of 
operand 2, subroutine SSTAT-IEKRSS deter- 
mines the relationship of that base address 
to the current base address (see note). If 
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they correspond, the SSTAT-IEKRSS subrou- 
tine sets the status of the base address of 
operand 2 to indicate that it is in a 
register and, therefore, need not be 
loaded; otherwise, it sets the status to 
indicate that it is in main storage. 



Subroutine SSTAT-IEKRSS sets the sta- 
tuses of the base addresses of operands 3 
and 1 in a similar manner. 



priate register is selected as shown in 
Table 3, and the register number is placed 
into the B2 field of the text entry. If 
the status of operand 2 indicates that it 
is in a register, subroutine SPLRA-IEKRSL 
does not assign a register to the base 
address of operand 2. The SPLRA-IEKRSL 
subroutine uses a similar procedure in 
assigning a register to the base address of 
operand 3, 



Note: The current base address is the last 
base address loaded for the purpose of re- 
ferring to an operand. This base address 
remains current until a subsequent operand 
that has a different base address is 
encountered. When this occurs, the base 
address of the subsequent operand must be 
loaded. That base address then becomes the 
current base address, etc. 



The SSTAT-ilEKRSS subroutine sets status 
of operand 1 to indicate whether or not the 
result of the interaction of operands 2 and 
3 is to be stored into operand 1. If 
operand 1 is either an actual operand (a 
variable defined by the programmer) or a 
temporary that is not used in the subse- 
quent text entry, it sets the status of 
operand 1 to indicate that the store opera- 
tion is to be performed; otherwise, it sets 
the status to indicate that a store; into 
operand 1 is unnecessary. 



Register Assignment ; After the status 
field of the I text entry is completed, sub- 
routine SPLRA-IEKRSL assigns registers to 
the operands ; of the text entry and their 
associated base addresses in the same order 
in which statuses were set for them. 



The assignment of registers depends upon 
the statuses; of the operands of the text 
entry. To assign a register to operand 2, 
subroutine SPLRA-IEKRSL examines the status 
of that operand, and, if necessary,, of 
operand 3. If the status of operand 2 
indicates that it is in a register or if 
the statuses! of operands 2 and 3 indicate 
that neither is a register, subroutine 
SPLRA-IEKRSL assigns operand 2 to a 
register. It selects the register accord- 
ing to the type of operand (see Table 3), 
and places the number of that register into 
the R2 field of the text entry. 



To assign a register to the base address 
of operand 2, subroutine SPLRA-IEKRSL 
determines the status of operand 2. If the 
status of that operand indicates that it is 
not in a register, it assigns a register to 
the base address of operand 2. The appro- 



If the status of operand 3 indicates 
that it is in a register, subroutine SPLRA- 
IEKRSL assigns the appropriate register 
(see Table 3) to that operand, and enters 
the number of that register into the R3 
field. 



Operand 1 is always assigned a register. 
Subroutine SPLRA-IEKRSL selects the regis- 
ter according to the type of operand 1 (see 
Table 3) , and places the number of that 
register into the Rl field. 



The base address of operand 1 is 
assigned a register only if the status of 
operand 1 indicates the result is to be 
stored into operand 1. If such is the 
case, subroutine SPLRA-IEKRSL selects the 
appropriate register, and records the 
number of that register in the Bl field. 
If the status of operand 1 indicates that 
the result is not to be stored into operand 
1, subroutine SPLRA-IEKRSL does not assign 
a register to the base address of operand 
1. 



When all the operands of the text entry 
and their associated base addresses are 
assigned registers, the next text entry is 
obtained, and the status setting and regis- 
ter assignment processes are repeated. 
After all text entries in the block are 
processed, control is returned to the con- 
trol routine of phase 20, which then makes 
the next block available to the basic reg- 
ister assignment routines. When the 
processing of all blocks is completed, con- 
trol is passed to the FSD. 



gjjj^j- Register As signment — 0PT=1 (Chart 
lU) 



During full register assignment (also 
refer to "Full Register Assignment — 
0PT=2"), as during basic register assign- 
ment, registers are assigned to the text 
entry operands and their associated base 
addresses, and the machine code to be 
generated for the text entries is speci- 
fied. To improve object module efficiency, 
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these functions are performed in a manner 
theit reduces the number of instructions 
required to load base addresses and 
opcirands. This process reduces the number 
of required load instructions by taking 
greater advantage of all available regis- 
ters, by assigning the registers as needed 
to both base addresses and operands, by 
keeping as many operands and base addresses 
as possible in registers and available for 
subsequent use, and by keeping the most 
active base addresses and operands in reg- 
isters where they are available for use 
throughout execution of the entire object 
module. 



A register is assigned to A at the point at 
which its value is defined, namely in the 
text entry A = X + Y. The same register is 
assigned to the subsequent uses of A. The 
value of A will be accumulated in the 
assigned register and can be used in the 
subsequent text entry C = A + Z, However, 
because A is also used in the text entry 
F = A + C, the contents of the register 
containing A cannot be destroyed by the 
code generated for the text entry 
C = A + Z. Thus, when the text entry 
C = A + Z is processed, instructions are 
specified for that text entry that use the 
register containing A, but that do not 
destroy the contents of that register. 



During full register assignment, regis- 
ters are assigned at two levels: "locally" 
and "globally. " Local assignment is per- 
formed on a block-by-block basis. Global 
assignment is performed on the basis of the 
entire module (if intermediate optimization 
has been specified). 



For local assignment, an attempt is made 
to keep operands whose values are defined 
within a block in registers and available 
for use throughout execution of that block. 
This is done by assigning an available reg- 
ister to an operand at the point at which 
its value is defined, (The value of an 
operand is defined when that operand 
appears in the operand 1 position of a text 
entry. ) The same register is assigned to 
subsequent uses (i,e,, operand 2 or operand 
3 appearances) of that operand within the 
block, thereby ensuring that the value of 
the operand will be in the assigned regis- 
ter and available for use. However, if 
more than one subsequent use of the defined 
operand occurs in the block, additional 
steps must be taken to ensure that the 
value of that operand is not destroyed 
between uses. Thus, when the text entries 
in which the defined operand is used are 
processed, the code specified for them must 
not destroy the contents of the register 
containing the defined operand. 



Because all available registers are used 
during full register assignment, a number 
of operands whose values are defined within 
the block can be retained in registers at 
the same time. 

Applying the above concept to an 
example, consider the following sequence of 
phase 15 text entries; 



A = X + Y 
C = A + Z 
F = A + C 



In the example, C is also defined and 
subsequently used. To that defined operand 
and its subsequent uses, a register is 
assigned. The assigned register is dif- 
ferent from that assigned to A, The value 
of C will be accumulated in the assigned 
register and can be used in the next text 
entry. The text entry F = A + C can then 
be evaluated without the need of any load 
operand instructions, because both the 
interacting operands (A and C) are in 
registers. 



This type of processing typifies that 
performed during local assignment for each 
block. When all blocks are processed, 
global assignment for the source module is 
carried out. 



Global assignment increases the effi- 
ciency of the object module as a whole by 
assigning registers to the most active 
operands and base addresses. The activi- 
ties of all operands and base addresses are 
computed during local assignment prior to 
global assignment. The first register 
available for global assignment is assigned 
to the most active operand or base address; 
the next available register is assigned to 
the next most active operand or base 
address; etc. As each such operand or base 
address is processed, a text entry, the 
function of which is to load the operand or 
base address into the assigned register, is 
generated and placed into the entry 
block (s) of the module. When the supply of 
operands and base addresses, or the supply 
of available registers, is exhausted, the 
process is terminated. 



All global assignments are recorded for 
usp in a subsequent text scan, which incor- 
porates global assignments into the text 
entries, and completes the processing of 
operands that have neither been locally nor 
globally assigned to registers (e.g., an 
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infrequently used operand that is used in a 
block but not defined in that blockJ. 



The full register assignment process is 
divided into five areas of operation: con- 
trol (subroutine REGAS-IEKRRG) , table 
building (subroutine FWDPAS-IEKRFP) , local 
assignment (subroutine BKPAS-IEKRBP) , glob- 
al assignment (subroutine GLOBAS-IEKRGB) , 
and text updating (subroutine STXTR- 
lEKRSX) . The control routine of phase 20 
(LPSEL-IEKPLS) passes control to subroutine 
REGAS-IEKRRG that directs the flow of con- 
trol among the other full register assign- 
ment routines. 



The actual assignment of registers is 
implemented through the use of tables built 
by the table-building routine, with assis- 
tance from the control routine. Tables are 
built using the set of coordinate numbers 
and associated dictionary pointers created 
by phase 15 (the MCOORD vector and MVD) for 
indexing. The table-building routine con- 
structs two sets of parallel tables. One 
set, used by the local assignment routine, 
contains information about a text block; 
the second set, used by the global assign- 
ment routines, contains information about 
the entire module. (The local assignment 
and global assignment tables are detailed 
in Appendix A, "Register Assignment 
Tables. ") 



The flow of control through the full 
register assignment routines is, as 
follows : 



1. The control routine (REGAS-IEKRRG) 
makes a pass over the MVD table and 
the dictionary entries for the 
variables and constants in the loop 
passed to it, and constructs the 
eminence table (EMIN) for the module, 
which indicates the availability of 
the variables for global assignment. 
Then the REGAS-IEKRRG subroutine calls 
the table building routine to process 
the blocks in the loop (the complete 
module for 0PT=1 ) . 



2. The table- building routine (FWDPAS- 
lEKRFP) builds the required set of 
local assignment tables and adds 
information to the global assignment 
tables under construction. Subroutine 
FWDPAS- lEKRFP selects the first block 
of the loop and builds the tables for 
that block. It then passes control to 
the local assignment routine to 
process the block and the tables (see 
Chart 15). 



3. The local assignment routine (BKPAS- 
IEKRBP) uses the tables supplied for 
the block to perform local register 
assignment, and returns control to 
subroutine FWDPAS-IEKRFP when its 
processing is completed (see Chart 
16). 



4. The FWDPAS-IEKRFP subroutine selects 
the next block of the loop and again 
builds tables. This process continues 
until all blocks of the loop have been 
processed. Control is then returned 
to the REGAS-IEKRRG subroutine. 



5. Subroutine REGAS-IEKRRG passes control 
to the global assignment routine 
GLOBAS-IEKRGB, which performs global 
assignment for the module (see Chart 
17). 



6. When global assignment is complete, 
the control routine calls the text 
updating routine, STXTR-IEKRSX, to 
complete register assignment by enter- 
ing the results of global assignment 
into the text entries for the module. 
Control is then returned to the LPSEL- 
IEKPLS subroutine. 



Table Building for Register Assignmen t 
(Chart 15) ; The table-building routine, 
FWDPAS-IEKRFP, performs a forward scan of 
the intermediate text entries for the block 
under consideration and enters information 
about each text entry into the local and 
global tables (see Appendix A, "Register 
Assignment Tables"). The local assignment 
tables can accommodate information for 100 
I text entries. If, however, a block con- 
tains more than 100 text entries, the 
table-building routine builds the local 
tables for the first 100 text entries and 
passes this set of tables to the local 
assignment routine. The local assignment 
routine processes the text entries repre- 
sented in the set of local tables. The 
table-building routine then creates the 
local tables for the next 100 text entries 
in the block and passes them to the local 
assignment routine. When the table- 
building routine encounters the last text 
entry for the block, it passes control to 
the local assignment routine, although 
there may be fewer than 100 entries in the 
local tables. 



The global tables contain information 
relating to variables and constants 
referred to within the module, rather than 
to text entries. The global tables can 
accommodate information for 126 variables 



Section 2: Discussion of Major Components 53 



and constants in a given module. Variables 
and constants in excess of this number 
within the module are not processed by the 
global assignment routine. 



L ocal Assignment (Chart 16) : Local assign- 
ment is implemented via a backward pass 
over the text items for the block (or por- 
tion of a block) under consideration. The 
text items are referred to by using the 
local assignment tables, which supply poin- 
ters to the text items. 



The local assignment routine, BKPAS- 
lEKRBP, examines each operand in the text 
for a block and determines (from the local 
assignment tables) whether or not the 
operand is eligible for local assignment. 
To be eligible, an operand must be defined 
and used (in that order) within a block. 
Because local assignment is performed via a 
backward pass over the text, an eligible 
operand will be encountered when it is used 
(i.e., in the operand 2 or 3 position) 
before it is defined. 



When a definition of the operand is 
encountered, subroutine BKPAS-IEKRBP enters 
the register assigned to the operand into 
the text item and sets the status for the 
operand to indicate its residence in a 
register. Once the register is assigned to 
the operand at its definition point, the 
BKPAS-IEKRBP subroutine frees the register 
by setting the entry in the register usage 
table to zero, making the register avail- 
able for assignment to another operand. 

If the block being processed contains a 
CALL statement or a reference to a function 
subprogram, common variables, arguments, 
and real operands cannot be assigned to 
registers across that reference. The local 
assignment routine assumes that: 

1. All mathematical functions return the 
result in general register or 
floating-point register 0, according 
to the mode of the function. 

2. The imaginary portion of a complex 
result is returned in floating-point 
register 2, 



When an operand of a text entry is 
examined, the local assignment routine 
(BKPAS-IEKRBP) consults the local assign- 
ment tables to determine that operand's 
eligibility. If the operand is eligible, 
subroutine BKPAS-IEKRBP assigns a register 
to it. The register assigned is determined 
by consulting the register usage table for 
local assignment (TRUSE). TRUSE is a work 
table that contains an entry for every 
register that may be used by the local 
assignment routine. A zero entry for a 
particular register indicates that the 
register is available for local assignment. 
A nonzero entry indicates that the register 
is unavailable and identifies the variable 
to which the register is assigned. The 
register usage table is modified each time 
a register is assigned or freed. The first 
time a register is assigned, a correspond- 
ing entry in the register usage table_f or 
global assignment (RUSE) is set. This 
entry implies that the register is unavail- 
able for global assignment. 

Subroutine BKPAS-IEKRBP records the 
register assigned to the used operand in 
the local assignment tables and in the text 
item containing the used operand. It sets 
the status of the operand in the text entry 
to indicate that it is in a register. If 
subsequent uses of the operand are encoun- 
tered prior to the definition of the 
operand, the BKPAS-IEKRBP subroutine uses 
the register assigned to the first use, and 
records its identity in the text item. It 
then sets the status bits for the operand 
to indicate that it is in a register and is 
to be retained in that register. 



If no register is available for assign- 
ment to an eligible operand, an overflow 
condition exists. In this case, subroutine 
BKPAS-IEKRBP must free a previously 
assigned register for assignment to the 
current operand. It scans the local as- 
signment tables and selects a register. It 
then modifies the local assignment tables, 
text entries for the block, and register 
usage table to negate the previous assign- 
ment of the selected register. The 
required register is now available, and 
processing continues in the normal fashion. 



Global Assi g nm ent (Chart 17) ; The global 
assignment routine (GLOBAS-IEKRGB) , unlike 
the local assignment routine, does not pro- 
cess any of the text entries for the 
module. The global assignment routine 
operates only through the set of global 
tables. The results of global assignments 
are entered into the appropriate text 
entries by the text updating routine. 

Before assigning registers, the global 
assignment routine modifies the global as- 
signment tables to produce a single activ- 
ity table for all operands and base 
addresses in the module. 

Global assignment is then performed 
based on the activity of the eligible 
operands and base addresses. 

The GLOBAS-IEKRGB routine determines the 
eligibility of an operand or base address 
by consulting the appropriate entry in the 
global assignment tables. Eligible 
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operands are divided into two categories: 
floating point and fixed point. The two 
categories aife processed separately, with 
floating-point quantities processed first. 

The register usage table for global as- 
signment (RUSE) is of the same type as 
described under local assignment (TRUSE) . 
For each category of operands, the GLOBAS- 
lEKRGB routine selects the eligible operand 
with the highest total activity and assigns 
it the first available register of the same 
mode. It records the assignment in the 
register usage table and in*, the global as- 
signment tables. The GLOBAS-IEKRGB routine 
then selects the eligible operand with the 
next highest activity and treats it in the 
same manner. ; Processing for each group 
continues until the supply of eligible 
operands or the supply of available regis- 
ters is exhausted. 

If the module contains any CALL state- 
ments or function subprogram references, 
arguments and real and common variables are 
ineligible for global assignment. In other 
words, if a module contains either a 
reference to ' a subroutine or to a function 
subprogram, global assignment is restricted 
to integer and logical operands theit are 
not in common or in the parameter list. 

Text Updating (Charts 18 and 19) ; The text 
updating routine (STXTR-IEKRSX) completes 
full register assignment. It scans each 
text entry within the series of blocks com- 
prising the module, looking at operands 2, 
3, and 1, in; that order, within each text 
entry. As each operand is processed, subrou- 
tine STXTR-IEKRSX interrogates the completed 
global assignment table to determine whether 
or not a global assignment has been made for 
the operand. If it has, subroutine STXTR- 
IFKRSX enters the register assicmed into the 
text entry and sets the operand status bits 
to indicate that the operand is in a regis- 
ter and is to be retained in that register. 

If both a; local and a global assignment 
have been made for an operand, the global 
assignment supersedes the local assignment 
and the STXTR-IEKRSX subroutine records the 
globally assigned register in the text 
items pertaining to that operand. It also 
sets the status bits for such an operand to 
indicate that it is in a register and is to 
be retained in that register. 

If a register has not been assigned 
either locally or globally for an operand, 
subroutine STXTR-IEKRSX determines and 
records in the text entry the required base 
register for the base address of that 
operand. If the base address corresponds 
to one that has been assigned to a register 
during global assignment, the STXTR-IEKRSX 
subroutine assigns the same register as the 
base register for the operand. If a 



register has not been assigned to the base 
address of the operand during global as- 
signment, it assigns a spill register 
(register 15) as the base register of the 
operand. Subroutine STXTR-IEKRSX sets the 
operand's base status bits to indicate 
whether or not the base address is in a 
register. (The base address will be in a 
register if one was assigned to it during 
global assignment. ) It then assigns the 
operand itself a spill register (general 
register or 1 or floating-point register 
0, depending upon its mode). 

As part of its text updating function, 
subroutine STXTR-IEKRSX allocates temporary 
storage where needed for temporaries that 
have not been assigned to a register, keeps 
track of the allocated temporary storage, 
and completes the register fields of text 
entries to ensure compatibility with phase 
25, On exit from the text updating rou- 
tine, all text items in the module are 
fully formed and ready for processing by 
phase 25. The text updating routine 
returns control to subroutine REGAS-IEKRRG 
upon completion of its functions. The 
REGAS-IEKRRG subroutine, in turn, returns 
control to subroutine LPSEL-IEKPLS. 



BRANCHING OPTIMIZATION — 0PT=1 



This portion of phase 20 optimizes 
branching within the object module. The 
optimization is achieved by generating RX- 
format branch instructions in place of RR- 
format branch instructions wherever 
possible. 

The use of RX-format branches eliminates 
the need for an instruction to load the 
branch address into a general register pre- 
ceding each branching instruction. Thus, 
branching optimization decreases the size 
of the object module by one instruction for 
each RR-format branch instruction in the 
object module that can be replaced by an 
RX-format branch instruction. It also 
decreases the number of address constants 
required for branching. 

Phase 20 optimizes branching instruc- 
tions by calculating the size of each text 
block (number of bytes of object code to be 
generated for that block) and by determin- 
ing those blocks that can be branched to 
via RX-format branch instructions. 

Subroutine BLS-IEKSBS calculates the 
sizes of all text blocks after full regis- 
ter assignment for the module is completed. 
It then uses the gathered block size infor- 
mation to determine the blocks to which a 
branch can be made by means of RX-format 
branch instructions. The BLS-IEKSBS sub- 
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routine calculates the number of bytes of 
object code by: 



Examining each text item operation 
code and the status of the operands 
(i.e., in registers or not). 



Determining, from a reference table, 
the number of bytes of code that is to 
be generated for that text item. 



The BLS-IEKSBS subroutine accumulates these 
values for each block in the module. In 
addition, it increments the block size 
count by the appropriate number of bytes 
for each reference to an in-line routine 
that it encounters. 



Next, subroutine B^S-IEKSBS computes all 
block sizes and determines those text 
blocks to which a branch can be made via 
RX-format branch instructions. Once con- 
verted to machine code, a branch can be 
made to a text block via an RX-format 
branch instruction if the relative address 
of the beginning of that block is displaced 
less than 4096 bytes from an address that 
is loaded into a reserved register. 



The following text discusses reserved 
registers, the addresses loaded into them, 
and the processing performed by subroutine 
BLS-IEKSBS to determine the source module 
blocks to which a branch can be made via 
RX-format branch instructions. 



Reserved Register Addresses 



The addresses placed into the reserved 
registers as a result of the execution of 
the initialization instructions (see 
"Generation of Initialization Instructions" 
under "FORTRAN System Director") are: 

• Register 13 — address of the save 
area. 

• Register 12 (if reserved) — address of 
the save area plus 409 6 or address of 
the first adcon for the program. 

• Register 11 (if reserved) — address of 
the register 12 plus 4096. 

• Register 10 (if reserved) — address of 
the register 12 plus 2(4096). 

• Register 9 (if reserved) — address of 
the register 12 plus 3(4096). 



Block Determination and Subsequent 
Processing 



Because the instructions resulting from 
the compilation are entered into text 
information immediately after the "B" block 
labels (see Figure 9), certain text blocks 
are displaced less than 4096 bytes from an 
address in a reserved register. A branch 
can be made to such blocks by RX-format 
branch instructions that use the address in 
a reserved register as the base address for 
the branch. 



Reserved Registers 



Reserved registers are allocated to con- 
tain the starting address of the adcon 
table and subsequent 4096-byte blocks of 
the object module. The criterion used by 
phase 20 in reserving registers for this 
purpose is the number of text entries that 
result from phase 15 processing, (Phase 
IScounts the number of text entries that 
result from its processing and passes the 
information to phase 20.) For small source 
modules (up to 880 text entries), phase 20 
reserves only one register in addition to 
register 13, For large source modules 
(more than 1760 text entries), a maximum of 
four additional registers is reserved. The 
registers are reserved, as needed, in the 
following order: register 13, 12, 11, 10, 
and 9. 



To determine the blocks to which a 
branch can be made via RX-format branch 
instructions, subroutine BLS-IEKSBS com- 
putes the displacement (using the block 
size information) of each block from the 
address in the appropriate reserved regis- 
ter. The first reserved register address 
considered is that in register 13. For 
each block that has a displacement of less 
than 4096 bytes from that address, subrou- 
tine BLS-IEKSBS enters the displacement 
into the statement number entry for that 
block. It also places in that statement 
number entry an indication that a transfer 
can be made to the block via an RX-format 
branch instruction, and records the number 
of the reserved register to be used in that 
branch instruction. 



When subroutine BLS-IEKSBS has processed 
all blocks displaced less than 4096 bytes 
from the address in register 13, it proc- 
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esses those that are displaced less than 
U096 bytes from the addresses in registers 
12, 11, 10, and 9 (if reserved) in a simi- 
lar manner. 



The information placed in the statement 
number entries is used during code genera- 
tion, a phase 25 process, to generate RX- 
format branch instructions. 



STRUCTURAL DETERMINATION 



chain of back dominators is effectively 
established for each block. This chain 
consists of the back dominator of the 
block, the back dominator of the back domi- 
nator of the block, etc. 



Figure 7 illustrates the concept of back 
dominators. Each block in the illustration 
represents a text block. The blocks are 
identified by single letter names. The 
back dominator of each block is identified 
and recorded above the upper right-hand 
corner of that block. 



To achieve 0PT=2 optimization, the 
structural determination routines of phase 
20 (TOPO-IEKPO and BAKT-IEKPB) identify 
module loops and specify the sequence in 
which they are to be processed. Loops are 
identified by analyzing the block connec- 
tion information gathered by phase 15 and 
recorded in the forward-connection (RMAJOR) 
and backward-connection (CMAJOR) tables. 
The connection information indicates the 
flow of control within the module and, 
therefore, reflects which blocks pass con- 
trol among themselves in a cyclical 
fashion. 



When all back dominators are identified, 
^ k§.2]S_target and a depth_number for each 
text block is determined. A block (block 
I) has a back target (block J) if: 



• There exists a path from block I to 
itself that does not pass through block 
J. 

• Block J is the nearest block in the 
chain of back dominators of block I 
that has only one forward connection. 



Loops are o"rdered for processing start- 
ing with the innermost, or most often 
executed, loop and working toward the out- 
ermost. The inner-to-outer loop sequence 
is specif ed sp that: 

• Text entries will not be relocated into 
loops that have already been 
processed. ^ 

• The full register capabilities of 
System/360 can first be applied to the 
most frequently executed (innermost) 
loop. 



Loop identification is a sequential 
process, which requires that a back domi- 
nator be determined for each text block. 
The back dominator of a text block (block 
I) is defined as the block nearest to block 
I through whibh control must pass before 
block I receives control for the first 
time. The back dominators of all text 
blocks must be determined before loop iden- 
tification can be continued. After all 
back dominators have been determined, a 



^The text optimization process relocates 
text entries from within an inner loop to 
an outer loop. Thus, if an outer loop 
were processed first, text entries from an 
inner loop might be relocated to the outer 
loop, thereby requiring that the outer 
loop be reprocessed. 



The text blocks constituting a loop are 
identifiable because they have a common 
back target, known as the back target of 
the loop. 

The depth number for a block indicates 
the degree to which that block is nested 
within loops. For example, if a block is 
an element of a loop that is contained 
within a loop with a depth number of one, 
that block has a depth number of two. All 
blocks constituting the same loop (i.e., 
all blocks having a common target) have the 
same depth number. 

The depth numbers computed for the 
blocks that comprise the various loops are 
used to determine the sequence in which the 
loops are to be processed. 

Figure 8 illustrates the concepts of 
back targets and depth numbers. Again each 
block in the illustration represents a text 
block, which is identified by a single 
letter name. In this illustration, the 
back target of each block is identified and 
recorded above the upper right-hand corner 
of that block. The depth number for the 
block is recorded above the upper left-hand 
corner of the block. Note that blocks that 
pass control among themselves in a looping 
fashion have a common back target and the 
same depth number. Also note that the 
blocks of the two inner loops have the same 
depth numbers, although they have different 
back targets. 
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When the back target and depth number of 
each text block has been determined, loops 
are identified and the sequence in which 
they are to be processed is specified. The 
loops are sequenced according to the depth 
number of their blocks. The loop whose 
blocks have the highest depth number is 
specified as the first to be processed, the 
loop whose blocks have the next highest 
depth number is specified as the second to 
be processed, etc. When the processing 
sequence of all loops has been established, 
the innermost loop is selected for 
processing. 

The following paragraphs describe the 
processing performed by the structural 
determination routines to: 

• Determine the back dominator of each 
text block. 

• Determine the back target and depth 
number of each text block. 

• Identify and sequence loops for 
processing. 



Determination of Back Dominators 



Figure 7. Back Dominators 
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Figure 8, Back Targets and Depth Numbers 



Subroutine TOPO-IEKPO determines the 
back dominator of each text block by 
examining the connection information for 
that block. The first block processed by 
subroutine TOPO-IEKPO is the first block 
(entry block) of the module. Blocks on the 
first level (i.e., blocks that receive con- 
trol from the entry block) are processed 
next. Second-level blocks (i.e., blocks 
that receive control from first-level 
blocks) are then processed, etc. 

The TOPO-IEKPO subroutine assigns to the 
entry block a back dominator of zero, 
because it has no back dominator; it re- 
cords the zero in the back dominator field 
of the statement number entry for that 
block (see Appendix A, "Statement Number/ 
Array Table"). The TOPO-IEKPO subroutine 
assigns each block on the first level eith- 
er its actual back dominator or a provi- 
sional back dominator. If a first-level 
block receives control from only one block, 
that block must be the entry block and is 
the back dominator for the first-level 
block. Subroutine TOPO-IEKPO records a 
pointer to the : statement number entry for 
the entry block in the back dominator field 
of the statement number entry for the 
first-level block. If a first-level block 
receives control from more than one block, 
subroutine TOPO-IEKPO assigns to it a pro- 
visional back dominator, which is the entry 
block of the module. All blocks on the 
first level are processed in this manner. 
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Subroutine TOPO-IEKPO also assigns each 
block on the second level either its actual 
back dominator or a provisional back 
dominator. If a second-level block 
receives control from only one block, its 
back dominator is the first-level block 
from which it receives control. The TOPO- 
IEKPO subroutine records a pointer to the 
statement number entry for the first-level 
block in the : back dominator field of the 
statement number entry for the second-level 
block. If more than one block passes con- 
trol to a second-level block, subroutine 
TOPO-IEKPO assigns to that block a provi- 
sional back dominator. The provisional 
back dominator assigned is a first-level 
block that passes control to the second- 
level block under consideration. Process- 
ing of this type is performed at each level 
until the last, or exit, block of the 
module is processed. Subroutine TOPO-IEKPO 
then determines the actual back dominators 
of blocks that were assigned provisional 
back dominators. 

For each block assigned a provisional 
back dominator, subroutine TOPO-IEKPO makes 
a backward trace over each path leading to 
the block (using CMAJOR) . The blocks at 
which two or more of the paths converge are 
flagged as possible candidates for the back 
dominator of the block. When all paths 
have been treated, the relationship of each 
possible candidate to the other possible 
candidates is examined. The TOPO-IEKPO 
subroutine assigns the candidate at the 
highest level: (i.e., closest to the entry 
block of the module) as the back dominator 
of the block under consideration; it re- 
cords a pointer to the statement number 
entry for the assigned back dominator in 
the back dominator field of the statement 
number entry for the block under considera- 
tion. After the back dominators of all 
text blocks aire identified, subroutine 
BAKT-IEKPB determines the back target and 
depth number of each text block. 



Determination of Back Targets and Depth 
Numbers 



Subroutine BAKT-IEKPB determines the 
back target of each text block through an 
analysis of the backward connection infor- 
mation (in CMAJOR) for that block. Block J 
is the back target of block I if: 

1. A path exists from block I to itself, 
and block J is the nearest block, in 
the chain of back dominators of block 
I, not on that path. 



2. 



Block J has only one forward 
connection. 



If a block J exists that satisfies con- 
dition 1 but not condition 2, then the back 
target of block J is also the back target 
of block I. 

If a block J satisfying condition 1 does 
not exist, then the back target of block I 
is zero. 

When the back target of a block is iden- 
tified, that block is also assigned a depth 
number. 

Back targets and depth numbers are 
determined for text blocks in the same 
sequence as back dominators are determined 
for them. The first block of the module is 
the first processed, first-level blocks are 
considered next, etc. 

The BAKT-IEKPB subroutine assigns the 
first or entry block both a back target and 
depth number of zero, because it does not 
have a back target and is not in a loop. 
It records the depth number (zero) in the 
loop number field of the statement number 
entry for the entry block (see Appendix A, 
"Statement Number/Array Table"). 

The processing performed by subroutine 
BAKT-IEKPB for each of the other blocks 
depends upon whether one or more than one 
block passes control to that block. If 
more than one block passes control to the 
block under consideration, subroutine BAKT- 
IEKPB makes a backward trace over all paths 
leading to that block to locate its primary 
£ath. The primary path of a block (if one 
exists) is a path that starts at that block 
and converges on that block without passing 
through any block in the chain of back 
dominators of that block. 

If such a path exists, subroutine BAKT- 
IEKPB obtains and examines the nearest 
block in the chain of back dominators of 
the block under consideration. If the 
obtained block has a single forward connec- 
tion, subroutine BAKT-IEKPB assigns that 
block as the back target of the block under 
consideration. The BAKT-IEKPB subroutine 
then assigns a depth number to the block. 
The number is one greater than that of its 
back target, because the block is in a 
loop, which must be nested within the loop 
containing the back target. Subroutine 
BAKT-IEKPB records the depth number in the 
loop number field of the statement number 
entry for the block. 

If the obtained block has more than one 
forward connection, subroutine BAKT-IEKPB 
assigns its back target as the back target 
of the block under consideration. The 
BAKT-IEKPB subroutine then records in the 
statement number entry for the block a 
depth number one greater than that of its 
back target. 
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If a block that receives control from 
two or more blocks does not have an asso- 
ciated primary path, that block, if it is 
in a loop at all, is in the same loop as 
one of the blocks in its chain of back 
dominators. To identify the loop contain- 
ing the block (block I), subroutine BAKT- 
lEKPB obtains and examines the nearest 
block to block I in its chain of back 
dominators that has two or more forward 
connections. The BAKT-IEKPB subroutine 
makes a backward trace over all paths lead- 
ing to the obtained block to determine 
whether or not block I is an element of 
such a path. If block I is an element of 
such a path, it is in the same loop as the 
obtained block, and subroutine BAKT-IEKPB, 
therefore, assigns block I the same back 
target and depth number as the obtained 
block; it records the depth number in the 
statement number entry for block I. 

If block I is not an element of any path 
leading to the obtained block, subroutine 
BAKT-IEKPB obtains the next nearest block 
to block I in its chain of back dominators 
that has two or more forward connections 
and repeats the process. If block I is not 
an element of any path leading to any block 
in its chain of back dominators, block I is 
not in a loop, and the BAKT-IEKPB subrou- 
tine assigns it both a back target and 
depth number of zero. 

A block that receives control from only 
one block, if it is in a loop at all, is in 
th€> same loop as one of the blocks in its 
chain of back dominators. To identify the 
loop containing a block (block I) that 
receives control from only one block, sub- 
routine BAKT-IEKPB obtains and examines the 
nearest block to block I in its chain of 
back dominators that receives control from 
two or more blocks. The BAKT-IEKPB subrou- 
tine makes a backward trace over all paths 
leciding to the obtained block to locate its 
primary path (if any). If the obtained 
block has a primary path, subroutine BAKT- 
IEKPB retraces it to determine whether or 
not block I is an element of the path. If 
it is, block I is in the same loop as the 
obtained block, and, BAKT-IEKPB therefore 
assigns block I the same back target and 
depth number as the obtained block; BAKT- 
IEKPB then records the depth ntamber in the 
statement number entry for block I. 

If the obtained block does not have a 
primary path, or if it does have a primary 
path, which, however, does not have block I 
as an element, the BAKT-IEKPB subroutine 
considers the next nearest block to block I 
in its chain of back dominators that 
receives control from two or more blocks. 
The process is repeated until a primary 
path containing block I is located (if any 
such path exists). If block I is not in 
the primary path of any block in its chain 



of back dominators, block I is not in a 
loop and subroutine BAKT-IEKPB assigns it 
both a back target and depth number of 



zero. 



i.^g.S!^J^fYJ!ng_g:^^_ Q^'^^^i"9 Loops for 
Processing 



Subroutine BAKT-IEKPB orders blocks for 
processing on the basis of the determined 
back target and depth number information. 
Blocks that have a common back target and 
the same depth number constitute a loop. 
The BAKT-IEKPB subroutine flags the loop 
with the highest depth number (therefore, 
the most deeply nested loop) as the first 
loop to be processed* It assigns the 
blocks constituting that loop a loop number 
of one, indicating that they form the 
innermost loop, which is the first to un- 
dergo optimization. (Subroutine BAKT-IEKPB 
records the value 1 in the loop number 
field of the statement number entry for 
each block in that loop. ) The BAKT-IEKPB 
subroutine flags the loop with the next 
highest depth number as the second loop to 
be processed. It assigns the blocks in 
that loop a loop number of two, indicating 
that they form the second (or next outer- 
most) loop to be processed. (A value of 2 
is recorded in the loop number field of the 
statement number entry for each block in 
that loop. ) Subroutine BAKT-IEKPB repeats 
this procedure until the loop with a depth 
number of one is processed. It then 
assigns the highest loop number to the 
blocks with a depth number of zero, indi- 
cating that they do not form a loop. 

If at any time, groups of blocks with 
the same depth number but different back 
targets are found, each group is in a dif- 
ferent loop. Therefore, each such loop is, 
in turn, processed before blocks having a 
lesser depth number are considered. Thus, 
if the blocks of two loops have the same 
depth number, subroutine BAKT-IEKPB assigns 
the blocks of the first loop the next loop 
number. It assigns the blocks of the 
second loop a loop number one greater than 
that assigned to the blocks of the first 
loop. 

When loop niombers are assigned to the 
blocks of all module loops, the sequence in 
which the loops are to be processed has 
been specified. Control is passed to the 
routine that determines the busy-on-exit 
information and then to the loop selection 
routine to select the first (innermost) 
loop to be operated upon. This loop con- 
sists of all blocks having a loop number of 
one. 
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BUSY-ON-EXIT INFORMATION 



Before the module can be processed on a 
loop-by-loop basis, the variables in each 
block must be classified as either busy-on- 
exit from the block or not busy-on-exit 
from the block. A variable is busy immedi- 
ately preceding a use of that variable, but 
is not busy immediately preceding a defini- 
tion of that variable. Thus, a variable is 
busy-on-exit from the blocks that are along 
all paths connecting a use and a prior 
definition of that variable. This means 
that in subsequent blocks the variable can 
be used before it is defined. The busy-on- 
exit condition for a variable assures that 
its proper value exists in main storage or 
in a register along each path in which it 
is subsequently used. 

Information about the regions in which a 
variable is busy or not busy determines 
whether or not a definition of that vari- 
able can be moved out of a loop. For 
example, if a variable is busy-on-exit from 
the back target of a loop, text optimiza- 
tion (see "Text Optimization") would not 
attempt to move to the back target a 
redefinition of that variable, because, if 
moved, the value of the variable, as it is 
processed along various paths from the back 
target, might not be the desired value. 
Conversely, if the variable is not busy-on- 
exit, the redefinition can be moved without 
affecting the desired value of the vari- 
able. Thus, text optimization respects the 
redefinitions of variables that are busy- 
on-exit from the back target of a loop. 

The information about regions in which a 
variable is busy or not busy also deter- 
mines whether or not load and store opera- 
tions of a register assigned to the vari- 
able are required. For example, in full 
register assignment (see "Full Register 
Assignment--0PT=2") , variables that are 
assigned registers during global assignment 
and that are busy-on-exit from the back 
target of the loop must have an initializ- 
ing load of the register placed into the 
back target. The load is required because 
the variable may be used before its value 
is defined. Conversely, if the globally 
assigned variable is not busy-on-exit from 
the back target, an initializing load is 
unnecessary. 

Phase 15 provides phase 20 with not 
busy-on-entry information for each operand 
that is assigned a coordinate (an MVD table 
entry). The not busy-on-entry information 
is recorded in the MVX field of the state- 
ment number text entry for each text block 
(see Phase 15, "Gathering Constant/Variable 
Usage Information"). An operand is not 
busy-on-entry to a block, if in that block 
that operand is defined but not used or 



defined before it is used. Phase 20 con- 
verts the not busy-on-entry information to 
busy-on-entry information. An operand is 
busy-on-entry to a block, if in that block 
that operand is used but not defined or 
used before it is defined. Finally, phase 
20 converts the busy-on-entry information 
to busy-on-exit information. The backward- 
connection information in CMAJOR is used to 
make the final conversion. 



The routine that performs the conver- 
sions is BIZX-IEKPZ. This routine deter- 
mines busy-on-exit information for each 
constant, variable, and base variable hav- 
ing an associated MVD table entry or coor- 
dinate. However, because only constants 
and base variables are used, they are busy- 
on-exit throughout the entire module. 
Therefore, the remainder of this discussion 
deals with the determination of busy-on- 
exit information for variables. 

Because RETURN statements (exit blocks) 
and references to subprograms not supplied 
by IBM constitute implicit uses of 
variables in common, all common variables 
and arguments to such subprograms are first 
marked as busy-on-entry to exit blocks and 
blocks containing the references. The com- 
mon variables and arguments are found by 
examining the information table entries for 
all variables in the MVD table. The module 
is then searched for blocks that are exit 
blocks and that contain references to sub- 
programs not supplied by IBM. The coordin- 
ate bit for each previously mentioned vari- 
able is set to on in the MVF field of the 
statement number text entry for each such 
block, while the same coordinate bit in the 
MVX field is set to off. This defines the 
variable to be busy-on-entry to such a 
block. During this process, a table, con- 
sisting of pointers to exit blocks, is 
built for subsequent use. 

After the previously discussed blocks 
have been appropriately marked for common 
variables and arguments, subroutine BIZX- 
IEKPZ, working with the coordinate assigned 
to a variable, converts the not busy-on- 
entry information for the variable to a 
table of pointers to blocks to which the 
variable is busy-on-entry. (The not busy- 
on-entry information for the variable is 
contained in the MVX fields of the state- 
ment number text entries for the various 
text blocks. ) At the same time, the varia- 
ble* s coordinate bit in each MVX field is 
set to off. The busy-on-entry table and 
CMAJOR are then used to set to on the MVX 
coordinate bit in the statement number text 
entry for each .block from which the vari- 
able is busy-on-exit. This procedure is 
repeated until all variables have been 
processed. Control is then returned to the 
LPSEL-IEKPLS subroutine. 
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To convert not busy-on-entry information 
to busy-on-entry information, subroutine 
BIZX-IEKPZ starts with the second MVD table 
entry, which contains a pointer to the 
variable assigned coordinate number two, 
and works down the chain of text blocks. 
The associated MVX coordinate bit in the 
statement number text entry for each block 
is examined. If the coordinate bit is off, 
the corresponding MVF coordinate bit is 
inspected. If the MVF coordinate bit is 
on, a pointer to the associated text block 
is placed into the busy-on-entry table. 
This defines the variable to be busy-on- 
entry to the block (i.e., the variable is 
used in the block before it is defined). 
If the associated MVX coordinate bit is on, 
indicating that the variable is not busy- 
on-entry, subroutine BIZX-IEKPZ sets the 
bit to off and proceeds to the next block. 
This process is repeated until the last 
text block has been processed. 

After the BIZX-IEKPZ subroutine has set 
to off the MVX coordinate bit (associated 
with the variable under consideration) in 
each statement number text entry and built 
a table of pointers to blocks to which the 
variable is busy-on-entry, it determines 
the blocks from which the variable is 
busy-on- exit. 

Starting with the first entry in the 
busy-on-entry table, subroutine BIZX-IEKPZ 
obtains (from CMAJOR) pointers to all 
blocks that are backward connection paths 
of that entry. Each backward-connecting 
block is examined to determine whether or 
not it meets one of three criteria, as 
follows : 

• The block contains a definition of the 
variable (i.e., the variable's MVS 
coordinate bit is on) . 

• The variable has already been marked as 
busy-on-exit from the block. 

• The block corresponds to the busy-on- 
entry table entry being processed. 



If the block meets one of these cri- 
teria, the variable is busy-on-exit from 
the block and its associated MVX coordinate 
bit is set to on, (The backward connection 
paths of that block are not explored, ) 

If the backward- connecting block does 
not meet any one of these criteria, the 
variable is marked as busy-on-exit from 
that block and that block's backward con- 
nection paths are, in turn, explored. The 
same criteria are then applied to the 
backward-connecting blocks. The backward 
connection paths are explored in this man- 
ner until a block in every path satisfies 
one of the criteria. 



If, during the examination of the back- 
ward connection paths, an entry block 
(i.e., a block lacking backward connection 
paths) is encountered, the blocks in the 
table of exit blocks, which was previously 
built by subroutine BIZX-IEKPZ are used as 
the backward connection paths for the entry 
block. Processing then continues in the 
normal fashion. 



When blocks in all backward connection 
paths have satisfied one of the criteria, 
the BIZX-IEKPZ subroutine obtains the next 
entry in the busy-on-entry table and re- 
peats the process. This continues until 
the busy-on-entry table has been exhausted. 

When the busy-on-entry table has been 
exhausted, the procedure of building the 
busy-on-entry table and converting it to 
busy-on-exit information is repeated for 
the next MVD table entry. When all MVD 
table entries have been processed, subrou- 
tine BIZX-IEKPZ passes control to the 
LPSEL-IEKPLS subroutine, which calls the 
loop selection routines. 



STRUCTURED SOURCE PROGRAM LISTING 



If both the EDIT option and 0PT=2 opti- 
mization are selected, after subroutine 
BIZX-IEKPZ has compiled the busy-on-exit 
information, control is passed to subrou- 
tine SRPRIZ-IEKQAA, which records on the 
SYSPRINT data set a structured source pro- 
gram listing. This listing indicates the 
loop structure and logical continuity of 
the source program, (A complete descrip- 
tion of the structured source listing is 
given in the publication IBM System/ 36 
Operating System; FORTRAN IV (G and H) 
Programmer's Guide , Form C28-6817. ) 

To produce the listing, subroutine 
SRPRIZ-IEKQAA reads the SYSUTl data set 
prepared by phase 10 and associates, by 
means of statement numbers, the individual 
source statements with the text blocks 
formed from them. By analysis of the loop 
number information gathered for the text 
blocks, the SRPRIZ-IEKQAA subroutine then 
identifies the source statements that make 
up a particular loop and flags them on the 
listing by corresponding loop number. Sub- 
routine routine SRPRIZ-IEKQAA also uses the 
previously gathered back dominator informa- 
tion to compute listing indentions for the 
statements. The indentions show dominance 
relationships; that is, subroutine SRPRIZ- 
IEKQAA indents the statements that form a 
text block from the statements that form 
the back dominator of that block. 
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LOOP SELECTION 



The phase 20 loop selection routine 
( TARGET- IEKPT) selects the loop to be proc- 
essed and provides the text optimization 
and full register assignment routines with 
the information required to process the 
loop. 

The loop to be processed is selected 
according to the value of a loop number 
parameter, which is passed to the loop 
selection routine. The phase 20 control 
routine (LPSEL-IEKPLS) sets this parameter 
to one after the process of structural 
determination is complete. The TARGET- 
lEKPT routine is called to select the loop 
whose blocks have a corresponding loop 
nximber. The selected loop is then passed 
to the text optimization routines. When 
text optimization for the loop is com- 
pleted, the control routine increments the 
parameter by one, sets the loop number of 
the blocks ini the loop just processed to 
that of their back target, and marks those 
blocks as completed. The LPSEL-IEKPLS rou- 
tine again calls the TARGET- IEKPT routine, 
which selects I the loop whose blocks corre- 
spond to the new value of the parameter. 
The selected loop is then passed to the 
text optimization routines. This process 
is repeated until the outermost loop has 
been text-optimized. 

After text optimization has processed 
the entire module (i.e., the last loop), 
the control routine removes the block com- 
pletion marks, initializes the loop number 
parameter to 1, and passes control to the 
TARGET- IEKPT routine to reselect the first 
loop. Control is then passed to the full 
register assignment routines. When full 
register assig:nment for the loop is com- 
pleted, the control routine marks the 
blocks of the loop as completed. It then 
increments the parameter by 1 and passes 
control to the TARGET- IEKPT routine to 
select the next loop. Full register as- 
signment is then carried out on the loop. 
This process is repeated until the outer- 
most loop has undergone full register as- 
signment. (Whien full register assignment 
has been carried out on the outermost loop, 
the LPSEL-IEKPLS routine passes control to 
the routine that computes the size of each 
text block and^ also the displacements 
required for branching optimization. ) 

The TARGET-IEKPT routine uses the value 
of the loop number parameter as a basis for 
selecting the loop to be processed. The 
TARGET-IEKPT routine compares the loop 
number assigned to each text block to the 
parameter. It marks each block having a 
loop number corresponding to the value of 
the parameter as an element of the loop to 
be processed. It does this by setting on a 



bit in the block status field of the state- 
ment number entry for the block (see Appen- 
dix A, "Statement Number/Array Table"). 
When all such blocks are marked, the loop 
has been selected. 

The information required by the text 
optimization and full register assignment 
routines to process the loop consists of 
the following: 

• A pointer to the back target of the 
loop (if any) . 

• Pointers to both the first and last 
blocks of the loop, 

• The loop composite matrixes. 

After the loop has been selected, this 
required information is gathered. 



Pointer to Back Target 



The text optimization and full register 
assignment routines place both relocated 
and generated text entries into the back 
target of the loop. Although the back tar- 
get of the loop was previously identified 
during structural determination, it was not 
saved. Therefore, its identity must be 
determined again. 

The TARGET-IEKPT routine determines the 
back target of the loop by obtaining the 
first block of the selected loop. It then 
analyzes the blocks in the chain of back 
dominators of the first block to locate the 
nearest block in the chain that is outside 
the loop and that passed control to only 
one block. That block is the back target 
of the loop, and the TARGET-IEKPT routine 
saves a pointer to it for use in the subse- 
quent processing of the loop. 



Pointers to First and Last Blocks 



The pointers to the first and last 
blocks of the selected loop indicate to the 
text optimization and full register as- 
signment routines where they are to initi- 
ate and terminate their processing. To 
make these pointers available, the TARGET- 
IEKPT routine merely determines the first 
and last blocks of the selected loop and 
saves pointers to them for use in the sub- 
sequent processing of the loop. To deter- 
mine the first and last blocks, the TARGET- 
IEKPT routine searches the statement number 
chain for the first and last entries having 
the current loop number. The blocks asso- 
ciated with those entries are the first and 
last in the loop. 
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Loo p Compos ite Mat rixes 



The loop composite matrixes, LMVS, LMVF, 
and LMVX, provide the text optimization and 
full register assignment routines with a 
summary of which operands are defined 
within the selected loop, which operands 
are used within that loop, and which 
operands are busy-on-exit from that loop. 
(An operand is busy-on-exit from the loop 
if it is used before it is defined in any 
path along which control flows from the 
loop. ) 



The LMVS matrix indicates which operands 
are defined within the loop. The TARGET- 
lEKPT routine forms LMVS by combining, via 
an OR operation, the individual MVS fields 
in the statement number text entry of every 
block in the selected loop. 



The LMVF matrix indicates which operands 
are used within the loop. The TARGET-IEKPT 
routine forms it by combining, via an OR 
operation, the individual MVF fields in the 
statement number text entry of every block 
in the selected loop. 



The LMVX matrix indicates which operands 
are busy-on-exit from the selected loop. 
LMVX is formed by the TARGET-IEKPT routine. 
It examines the text entries of each block 
that is not in the selected loop and that 
receives control from a block in that loop. 
Any operand in the text entries of such a 
block that is either used but not defined 
in the block or used before it is defined 
is busy-on-exit from the loop. The TARGET- 
IEKPT routine sets to on the bit in the 
LMVX matrix that corresponds to the coor- 
dinate assigned to each such operand to 
reflect that it (i.e., the operand) is 
busy-on-exit from the loop. 



TEXT OPTIMIZATION — 0PT=2 



The text optimization process of phase 
20 detects text entries within the loop 
under consideration that do not contribute 
to the loop's successful execution. These 
non-essential text entries are either com- 
pletely eliminated or are relocated to a 
block outside of the current loop. Because 
the most deeply nested loops are presented 
for optimization first, the numbe;r of text 



entries in the most strategic sections of 
the object module will approach a minimum. 

The processing of text optimization is 
divided into three logical sections: 

• Common expression elimination optimizes 
the execution of a loop by eliminating 
unnecessary recomputations of identical 
arithmetic expressions. 

• Backward movem ent optimizes the execu- 
tion of a loop by relocating to the 
back target computations essential to 
the module but not essential to the 
current loop. 

• Strength reduction optimizes the incre- 
mentation of DO indexes and the compu- 
tation of subscripts within the current 
loop. Modification of the DO increment 
may allow multiplications to be relo- 
cated into the back target. If the DO 
increment is not busy-on-exit from the 
loop, it may be completely replaced by 
a new DO increment that becomes both a 
subscript value and a test value at the 
bottom of the DO loop. 



The first two of the foregoing sections 
are similar in that they examine text en- 
tries in strict order of occurrence within 
the loop. 

The last section does not examine indi- 
vidual text entries within the loop; 
instead, the TYPES table, constructed prior 
to their execution, is consulted for opti- 
mization possibilities. Furthermore, an 
iSt^£§:£ti2D °f entries in the TYPES table 
must exist before processing can proceed. 
The TYPES table contains pointers to type 
3, 5, 6, and 7 text entries. The various 
types, their definitions, and the section (s) 
of text optimization that process them 
are outlined in Table 4. Pointers to type 
1 and type 2 text entries are not entered 
into the TYPES table. The reason is that 
such types have already been processed dur- 
ing backward movement. 

The following text describes the 
processing performed by each of the sec- 
tions of the text optimization. Table 11 
summarizes the criteria for performing text 
optimization in each section. An example 
illustrating the type of processing of each 
section is given in Appendix D. These 
examples should be referred to when reading 
the text describing the processing of the 
sections. 
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• Table U. Text Entry Types 



Type 



Definition 



Processed by 



Type 1 i A text entry having an absolute constant^ 
] in both the operand 2 and operand 3 
I position. 



Backward Movement (elimination) 



Type 2 j A text entry having stored constants^ in 

f both the operand 2 and operand 3 positions. 



Backward Movement (movement) 



Type 3 



An inert text entry (i.e., a text entry 
that is a function of itself and an addi- 
tive constant; e.g., J=J+l) , 



Strength Reduction 



Type 5 



A text entry whose operand 1 (a temporary) 
is a function of a variable (or temporary) 
and a constant, and whose operator is 
multiplicative (♦ or / ). 



Strength Reduction 



Type 6 



A text entry whose operand 1 (a temporary) 
is a function of a variable (or temporary) 
and a constant, and whose operator is 
additive (+ or - ). 



Strength Reduction 



.| 

I Strength Reduction 



Type 7 j A branch text entry 

JL . . 



^Absolute constants are those that agree with the definition of numerical constants as 
stated in the publication IBM Svstem/360 Operating System; FORTRAN IV Lang uage , Form 
C28-6515, 

2A stored constant is a variable that is not defined within a loop and, thus, its 
value remains constant throughout execution of that loop. 



Common Expression Elimination — 0PT=2 



The object of common expression elimina- 
tion, which is carried out by subroutine 
XPELIM-IEKQXM, is to get rid of any unnec- 
essary arithmetic expressions. This is 
accomplished by eliminating text entries, 
one at a time, until the entire expression 
disappears. An arithmetic text entry is 
unnecessary if it represents a value (cal- 
culated elsewhere in the loop) that may be 
used without modification. A value may be 
used without modification if, between 
appearances of the same computation, 
operands 2 and 3 of the text entry are not 
redefined. The following paragraphs dis- 
cuss the processing that occurs during com- 
mon expression elimination. 

within the current loop, subroutine 
XPELIM-IEKQXM examines each uncompleted 
block (i.e., a block that is not part of an 
inner loop) for text entries that are can- 
didates for elimination, A text entry is a 
candidate if it contains an arithmetic, 
I binary, logical, or subscript operator. 
Once a candidate is found, the XPELIM- 
IEKQXM subroutine attempts to locate a 
matching text entry, A text entry matches 
the candidate if operand 2, operand 3, and 
the operator of that text entry are ident- 
ical to those of the candidate. If either 



operand 2 or 3 of the matching text entry 
is redefined between that text entry and 
the candidate, the match is not accepted. 
The search for the matching text entry 
takes place in the following locations: 

• In the same block as the candidate, 
between the first text entry and the 
candidate. 

• In a back dominator (see note) of the 
block in which the candidate resides. 

Note; Only back dominator s that are 
not elements of previously processed 
loops and that are within the confines 
of the current loop are considered. 
The first back dominator considered is 
the one nearest to the block being 
processed. The next considered is the 
back dominator of the nearest back 
dominator, etc. 

When a matching text entry is found, 
subroutine XPELIM-IEKQXM performs elimina- 
tion in the following way: 

• If operand 1 of the matching text entry 
is not redefined between that text 
entry and the candidate, subroutine 
XPELIM-IEKQXM substitutes that operand 
for operand 2 of the candidate and con- 
verts the operator to a store. 
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• If, however, operand 1 is redefined, 
subroutine XPELIM-IEKQXM generates a 
text entry to save the value of operand 
1 in a temporary and inserts this text 
entry into text immediately after the 
matching text entry. It then replaces 
operand 2 of the candidate with this 
temporary, and converts the operator to 
a store. 



• Finally, if operand 1 of the candidate 
is a temporary generated by phase 15, 
the XPELIM-IEKQXM subroutine replaces 
all uses of the temporary with the new 
operand 2 of the candidate and deletes 
the candidate. Thus, the value of the 
matching text entry is propagated for- 
ward for a possible match with another 
candidate. This provides the link to 
the next text item of the complete com- 
mon expression. 



All text entries in the block under con- 
sideration are processed in the previously 
described manner. When the entire block is 
processed, the next uncompleted block in 
the loop is selected and its text entries 
undergo common expression elimination. 
When all uncompleted blocks in the loop are 
processed, control is returned to the phase 
20 control routine, which passes control to 
the portion of phase 20 that continues text 
optimization through backward movement. 

The overall logic of common expression 
elimination is illustrated in Chart 11. An 
example of common expression elimination is 
given in Appendix D, 



Backward Movement — 0PT=2 



• If operand 1 of the candidate is not 
busy-on-exit from the back target of 
the loop and if operand 1 of the candi- 
date is not defined elsewhere in the 
loop, the BACMOV-IEKQBM subroutine 
moves the entire candidate to the back 
target of the loop. (An operand is not 
busy-on-exit from the back target if 
that operand is defined in the loop 
before it is used. ) 

• If operand 1 of the candidate is busy- 
on-exit from the back target of the 
loop or if it is defined elsewhere in 
the loop, subroutine BACMOV-IEKQBM 
generates a text entry to perform the 
computation of the expression in the 
candidate and store the result in a new 
temporary. It moves this text entry to 
the end of the back target of the loop 
and then replaces the expression in the 
candidate with operand 1, the new tem- 
porary, of the generated text entry. 

All the text entries in the block under 
consideration are processed in the pre- 
viously described manner. When the entire 
block is processed, the next uncompleted 
block in the loop is selected and its text 
entries undergo backward movement. When 
all uncompleted blocks in the loop are 
processed, control is returned to the phase 
20 control routine, which passes control to 
the portion of phase 20 that continues text 
optimization through strength reduction. 

The overall logic of backward movement 
is illustrated in Chart 12. An example of 
backward movement is given in Appendix D. 

Two additional optimization processes 
are performed concurrently with backward 
movement. They are the elimination of 
simple stores and of arithmetic expressions 
that appear in text entries and are func- 
tions of constants. 



Backward movement, which is performed by 
subroutine BACMOV-IEKQBM, moves text 
entries from a loop to an area that is 
executed less often, the back target of the 
loop. During backward movement, each 
uncompleted block in the loop being proc- 
essed is examined for text entries that are 
candidates for backward movement. To be a 
candidate for backward movement, a text 
entry must be type 2. Therefore, it must: 

• Contain an arithmetic or logical 
operator. 

• Have operands 2 and 3 that are not 
defined within the loop. 

When a candidate is found, subroutine 
BACMOV-IEKQBM carries out backward movement 
of that candidate in one of two ways : 



Elimination of Simple Stores ; The BACMOV- 
IEKQBM subroutine effects the removal of 
unnecessary simple stores (i,e,, text 
entries of the form "operand 1 = operand 
2") from the block that is currently un- 
dergoing backward movement. The following 
paragraph describes the processing. 

Svibroutine BACMOV-IEKQBM selects as can- 
didates for elimination any simple store in 
which operand 1 is a nonsubscripted vari- 
able. Pointers to the candidates are 
passed to the SUBSUM-IEKQSM subroutine, 
which determines if elimination is indeed 
possible according to the conditions illus- 
trated in Table 5. At the same time, sub- 
routine SUBSUM-IEKQSM replaces all uses of 
operand 1 of the candidate with operand 2 
of the candidate in text entries between 
either: 
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• The candidate and the first redefini- 
tion of either operand. 

• The candidate and the end of the block. 



The BACMOV- lEKQBM subroutine then deletes 
those candidates so marked by subroutine 
SUBSUM-IEKQSM. An example of simple-store 
elimination is illustrated in Appendix D, 



Table 5. Operand Characteristics That 

Permit Simple-Store Elimination 
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Elimination of Text Entr y E xpressions 
I nvolv ing Integer „ Consta nts (Type 1) : Dur- 
ing the scan of a block for text entries to 
be moved to the back target, subroutine 
BACMOV- lEKQBM also checks for text entries 
whose operators are arithmetic and whose 
operands 2 and 3 are both integer con- 
stants. When such a text entry is found, 
the BACMOV- lEKQBM subroutine eliminates the 
arithmetic expression in the text entry by: 



• Calculating the result of the 
expression. 

• Creating: a new dictionary entry for the 
result, which is a constant. 

• Replacing the arithmetic expression 
with the result. 



The text entry is thereby reduced to a 
simple store, which may be eliminated by 
simple-store elimination. 



Streng th Reduction -- 0PT=2 



Strength reduction, which is performed 
by subroutine REDUCE-IEKQSR, optimizes 
loops that are controlled by logical IF 
statements. (DO loops are converted to 
loops controlled by logical IF statements 
during phase 10 processing. ) Such loops 
are optimized by modifying the expression 
(e.g., J < 20) in the IF statement; this 
enables certain text entries to be moved 
from the loop to the back target of the 
loop, an area executed less frequently. 
Strength reduction processing is divided 
into two sections: 

• Elimination of multiplicative text. 

• Elimination of additive text. 

Both of these sections perform strength 
reduction, but each has a separate set of 
criteria for considering a loop as a candi- 
date for reduction. However, the manner in 
which each section implements reduction 
essentially is the same. 



Elimination of Multiplicative T ext : To 
eliminate multiplicative text, subroutine 
REDUCE-IEKQSR examines the loop being proc- 
essed to determine whether or not it is a 
candidate for strength reduction. The loop 
is a candidate if: 

• The loop contains an inert text entry 
(type 3). 

• Operand 1 of the inert text entry is 
used in another text entry (in the 
loop) whose operator indicates multi- 
plication and whose other used operand 
is a constant^ (type 5). 

• Operand 1 of the inert text entry is 
the variable appearing in the expres- 
sion of the logical IF statement that 
controls the loop. 



If the loop is a candidate, subroutine 
REDUCE-IEKQSR implements strength reduction 
in one of two ways: 

1. If the constants in the inert text 
entry and the multiplicative text 
entry are both absolute constants, the 
REDUCE-IEKQSR subroutine: 

a. Calculates a new constant (K) 

equal to the product of the abso- 
lute constants. 



^This other text entry is referred to as a 
multiplicative text entry. 
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b. Generates another inert text entry 
and inserts it into the loop imme- 
diately after the original inert 
text entry. The additive constant 
in this text entry is K. 

c. Modifies the expression in the 
logical IF statement by: 

(1) Replacing the branch variable 
(see note) with operand 1 of 
the generated inert text 
entry. 

(2) Replacing the branch constant 
(see note) with a constant 
equal to the product of the 
branch constant and the abso- 
lute constant in the multipli- 
cative text entry. 

d. Deletes the original inert text 
entry if operand 1 of that text 
entry is not busy-on-exit from the 
loop. 

e. Moves the multiplicative text 
entry to the back target of the 
loop. 

f. Replaces operand 1 of the multi- 
plicative text entry with operand 
1 of the generated inert text 
entry. 

g. Replaces the uses of operand 1 of 
the multiplicative text entry that 
remain in the loop with operand 1 
of the generated inert text entry. 

Note; The branch variable is the 
variable in the expression of the 
logical IF statement that is 
tested to determine whether or ndt 
the loop is to be re-executed, . 
The branch constant is the con- 
stant with which the branch vari- 
able is compared. For example, in 
IF (J < 3) where J is the branch 
variable and 3 is the branch 
constant, 

2. If either of the constants in the 

inert text entry or the multiplicative 
text entry is a stored constant, the 
REDUCE- lEKQSR subroutine performs 
similar processing to that described 
above. However, prior to generating 
the inert text entry, it generates an 
additional text entry and places it 
into the back target of the loop. 
This text entry multiplies the two 
constants. Operand 1 of this text 
entry becomes the additive constant in 
the generated inert text entry. In 
the case where the constant in the 
multiplicative text entry is a stored 
constant, a second additional text 



entry is generated and placed into the 
back target of the loop. This second 
text entry multiplies the branch con- 
stant by the constant in the multipli- 
cative text entry. Operand 1 of the 
second text entry becomes the new 
branch constant of the logical IF. 

If additional multiplicative text 
entries exist within the loop, the forego- 
ing process is repeated. Repetitive proc- 
essing of this type results in a number of 
generated inert text entries, which may be 
eliminated from the loop by the processing 
of the second section of strength 
reduction. 



liiiDill^tion_of_Additive_Text: To eliminate 
additive text, subroutine REDUCE-IEKQSR 
examines the loop being processed to deter- 
mine whether or not it is a candidate for 
strength reduction. The loop is a candi- 
date if: 

• The loop contains an inert text entry 
(type 3). 

• Operand 1 of the inert text entry is 
used in the loop in another text entry 
whose operator indicates addition^ 
(type 6). 

If the loop is a candidate, the proc- 
essing performed by subroutine REDUCE- 
IEKQSR to eliminate the additive text entry 
is essentially the same as that performed 
to eliminate a multiplicative text entry. 

The overall logic of strength reduction 
is illustrated in Chart 13. An example 
showing both methods of strength reduction 
is given in Appendix D, 



FULL REGISTER ASSIGNMENT — 0PT=2 (CHART 
14) 



During 0PT=2 optimization, full register 
assignment is carried out on module loops, 
rather than on the entire module, as is the 
case for 0PT=1 optimization. Regardless of 
whether a loop or the entire module is 
being processed, the full register assign- 
ment routines operate essentially in the 
same manner. However, the optimization 
effect of full register assignment, when 
carried out on a loop-by-loop basis, is 
more pronounced. Because the most deeply 
nested loops are presented for full regis- 
ter assignment first, the number of regis- 
ter loads in the most strategic sections of 



^This text entry is referred to as an addi- 
tive text, entry. 



68 



the object module approaches a minimum. 
The processing of a loop by full register 
assignment differs from the processing of 
the entire module only in the area of glob- 
al assignment. An understanding of the 
processing performed on a loop, other than 
global assignment, can be derived from the 
previous discussion of full register 
assignment (see "Full Register Assignment 
— 0PT=1"). Global assignment for a loop 
is described in the following text. 

When processing a loop, the global 
assignment routine (GLOBAS-IEKRGB) in- 
corporates into the current loop, wherever 
possible, the global assignments made to 
items (i.e., operands and base addresses) 
in previously processed loops. It does 
this to ensure that the same register is 
assigned in both loops if an item eligible 
for global assignment in the current loop 
was globally assigned in a previously proc- 
essed loop. 

Before the; global assignment routine 
assigns ah available register to the most 
active item of the current loop, it deter- 
mines whether that item was globally 
assigned in a previously processed loop. 
(As global assignment is carried out on 
each loop, all global assignments for that 
loop are recorded and saved for use when 
the next loop is considered. ) If the item 
was not globally assigned in a previously 
processed loop, the GLOBAS-IEKRGB routine 
assigns it the first available register. 
If the item was globally assigned in a pre- 
viously processed loop, the global assign- 
ment routine then determines whether or not 
the register assigned to the item in the 
previously processed loop is currently 
available. If that register is available, 
the GLOBAS-IEKRGB routine also globally 
assigns it to the same item in the current 
loop. If the register is not available, 
the global assignment of that item in the 
previously processed loop cannot be in- 
corporated into the current loop. The 
GLOBAS-IEKRGB; routine, therefore, assigns 
the item an available register different 
from that assigned to it in the previously 
processed loop. The GLOBAS-IEKRGB routine 
selects the eligible item with the next 
highest activity in the current loop and 
treats it in the same manner. Processing 
continues in this fashion until the supply 
of eligible items or the supply of avail- 
able registers is exhausted. 

As each global assignment is made to an 
active item, the GLOBAS-IEKRGB routine 
checks to determine whether or not that 
item is busy-on-exit from the back target 
of the loop. If the item is busy-on-exit, 
the GLOBAS-IEKRGB routine generates a text 
entry to load that item into the assigned 
register and inserts it into the back tar- 
get of the loop. The load is required to 



guarantee that the item is in a register 
and available for subsequent use during 
loop execution. If the item is not busy- 
on-exit, the text item is not required to 
be loaded. If any globally assigned item 
is defined within the loop and is also 
busy-on-exit from the loop, the GLOBAS- 
IEKRGB routine generates a text entry to 
store that item on exit from the loop. The 
generated store is needed to preserve the 
value of such an operand for use when it is 
required during the execution of an outer 
loop. 

The GLOBAS-IEKRGB routine records all 
global assignments made for the current 
loop for use in the subsequent updating 
scan (see "Full Register Assignment — 
0PT=1") and also for incorporation, wherev- 
er possible, into subsequently processed 
loops. 



BRANCHING OPTIMIZATION — 0PT=2 



During 0PT=2 optimization, branching 
optimization is carried out in the same 
manner as during 0PT=1 optimization. After 
all loops have undergone full register 
assignment, subroutine BLS-IEKSBS is given 
control to calculate the size of each 
block. When the sizes of all blocks have 
been calculated, the BLS-IEKSBS subroutine 
uses the block size information to deter- 
mine the blocks to which a branch can be 
made by means of RX-format branch 
instructions. 



PHASE 25 



Phase 25 completes the production of an 
object module from the combined output of 
the preceding phases of the compiler. An 
object module consists of four elements: 

• Text information. 

• External symbol dictionary. 

• Relocation dictionary, 

• Loader END record. 



The text information (instructions and 
data resulting from the compilation) is in 
a relocatable machine language format. It 
may contain unresolved external symbolic 
cross references (i.e., references to sym- 
bols that do not appear in the object 
module). The external symbol dictionary 
contains the information needed to resolve 
the external symbolic cross references that 
appear in the text information. The relo- 
cation dictionary contains the information 
needed to relocate the text information for 
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execution. The END record informs the 
linkage editor of the length of the object 
module and the address of its main entry 
point. 

An object module resulting from a compi- 
lation consists of a single control sec- 
tion, unless common blocks are associated 
with the module. An additional control 
section is included in the module for each 
common block. 

The object module produced by phase 25 
is recorded on the SYSLIN data set if the 
LOAD option is specified by the FORTRAN 
programmer, and on the SYSPUNCH data set if 
the DECK option is specified. If the LIST 
option is specified, phase 2 5 develops and 
records on the SYSRINT data set a pseudo- 
assembler language listing of the instruc- 
tions and data of the object module. If 
the MAP option is specified, phase 25 also 
produces a storage map. If the ID option 
is specified, phase 25 inserts information 
into the object module which is used by the 
object-time traceback routine (see Appendix 
E: Object-Time Library Subprograms). 



TEXT INFORMATION 



record. Thus, the address field of the TXT 
record indicates the relative address of 
the instructions and data that are placed 
into the record. 

Figure 9 shows the layout of storage 
that phase 25 assumes in setting up text 
information. 

Phase 25 constructs text information by: 

• Reserving address constants for the 
referenced statement numbers of the 
module, 

• Completing the processing of the adcon 
table entries and entering the result- 
ant entries into TXT records. 

• Generating the prologue and epilogue 
instructions and entering these 
instructions into TXT records. 

• Converting phase 15/phase 20 text into 
System/360 machine code and entering 
the code into TXT records. 



Chart 20 shows the overall logic of 
phase 25 processing. 



Text information consists of the machine 
language instructions and data resulting 
from the compilation. Each text informa- 
tion entry (a TXT record) constructed by 
phase 25 can contain up to 56 bytes of 
instructions and data, the address of the 
instructions and data relative to the 
beginning of the control section, and an 
indication of the control section that con- 
tains them. A more detailed discussion of 
the use and format of TXT records is given 
in the publication IBM Svstem/360 Operating 

System ; Linkage Editor, PEQgrag-^QgiS 

Manual, Form Y28-6610. 

The major portion of phase 25 processing 
is concerned with text information con- 
struction. In building text information, 
phase 2 5 obtains each item that is to be 
placed into text information, converts the 
item to machine language format wherever 
necessary, enters the item into a TXT rec- 
ord, and places the relative address of the 
item into the TXT record. 

Phase 25 assigns relative addresses by 
means of a location counter, which is con- 
tinually updated to reflect the location at 
which the next item is to be placed into 
text information. Whenever phase 25 begins 
the construction of a new TXT record, it 
inserts the current value of the location 
counter into the address field of the TXT 



Address Constant Reservation 



Before it constructs text information, 
subroutine MAINGN-IEKTA reserves address 
constants for the referenced statement num- 
bers of the module and for the statement 
numbers appearing in computed GO TO state- 
ments. The address constants are reserved 
so that the relative addresses of the 
statements associated with such statement 
numbers can be recorded and, subsequently, 
obtained during execution of the object 
module, when branches to those statements 
are required. 

To reserve address constants for state- 
ment numbers, subroutine MAINGN-IEKTA scans 
the chain of statement number entries in 
the statement niimber/array table. For each 
encountered statement number to which 
reference is made, subroutine MAINGN-IEKTA 
inserts a base and displacement into the 
associated statement number entry. When 
the text representation of that statement 
number is encountered, a relative address 
is placed in the statement number entry. 

Not e; If branching optimization is being 
implemented, subroutine MAINGN-IEKTA does 
not perform the processing described in the 
previous paragraph. 
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*See "Relative Address Assignment" under "CORAL Processing." 
**See last paragraph of "Generation of Initialization Instructions" under "FORTRAN System Director." 

• Figure 9. storage Layout for Text Information Construction 



After all statement numbers are proc- 
essed, bases: and displacements are likewise 
assigned to adcons for the statement num- 
bers appearing in computed GO TO 
statements. The MAINGN-IEKTA subroutine 
scans the branch table chain (see Appendix 
A, "Branch Tables"), and assigns a base and 
displacement for each branch table. Sub- 
routine MAINGN-IEKTA does not record poin- 
ters to the address constants set aside for 
the actual statement numbers of the com- 
puted GO TO statements in their associated 
standard branch table entries. The values 
to be placed into the address constants for 
statement numbers in computed GO TO 
statements are also determined during text 
conversion. 



Text Conversion 

Phase 25 converts intermediate text into 
System/360 machine code. (The text conver- 



sion process is controlled by subroutine 
MAINGN-IEKTA. > In converting the text, 
phase 25 obtains each text entry and, 
depending upon the nature of the operator 
in the text entry, passes control to one of 
six processing paths to convert the text 
entry. 

The six processing paths are: 

• Statement Number Processing. 

• Input/output Statement Processing. 

• CALL Statement Processing. 

• Code Generation, 

• RETURN Statement Processing. 

• END Statement Processing. 

See Table 14 for the complete list of 
subroutines called by phase 25. 

STATEMENT_NyMBER_PRgCESS ING : When the 
operator of the text entry indicates a 
statement number, subroutine MAINGN-IEKTA 
passes control to subroutine LABEL-IEKTLB. 
The LABEL-IEKTLB subroutine then inserts 
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the current value of the location counter, 
which is the relative address of the state- 
ment associated with the statement number, 
into the statement number entry. All 
branches to that statement are made through 
the use of the relative address for that 
statement number. 



Note: If branching optimization is being 
implemented, only statement numbers to 
which a branch cannot be made via RX- format 
branch instructions (i.e., statement num- 
bers that are not within the range of 
I registers 13, 12, 11, 10, and 9) are proc- 
essed as described above. 



After the relative address has been 
placed into the statement number entry, 
subroutine LABEL-IEKTLB determines whether 
or not that statement number appears in a 
computed GO TO statement. If it does, sub- 
routine LABEL-IEKTLB also inserts the rela- 
tive address into the appropriate field of 
the branch table entry, or entries, for 
that statement number. The relative 
address recorded in the branch table entry 
is placed into the storage reserved for it 
within text information (see "END Statement 
Processing") when the text representation 
of the END statement is encountered. 



INPUT/OUTPUT STATEMENT PROCESSING : When 
the operator of the text entry indicates an 
input/output statement, an I/O list item, 
or the end of an I/O list, the MAINGN-IEKTA 
subroutine passes control to subroutine 
lOSUB-IEKTIS, which generates an appropri- 
ate calling sequence to IHCFCOMH to per- 
form, at object-time, the indicated 
operation. 

The calling sequence generated for an 
input/output statement depends on the type 
of the statement (e.g., READ, BACKSPACE). 
The calling sequence generated for an I/O 
list item depends on the input/output 
statement type with which the list item is 
associated and on the nature of the list 
item, i.e., whether the item is a variable 
or an array. The calling sequence 
generated for an end of an I/O list depends 
on whether the end I/O list operator 
signals : 

• The end of an I/O list associated with 
a READ/WRITE that requires a FORMAT 
statement. 

• The end of an I/O list associated with 
a READ/WRITE that does not require a 
FORMAT Statement. 

Once the calling sequence is generated, 
subroutine lOSUB-IEKTIS enters it into TXT 
records . 



CALL STATEMENT PROCESSI NG; When the opera- 
tor of the text entry indicates a CALL 
statement, subroutine MAINGN-IEKTA passes 
control to subroutine FNCALL-IEKVFN to gen- 
erate a standard direct- linkage calling 
sequence, which uses general register 1 as 
the argument register. The argument list 
is located in the adcon table in the form 
of address constants. Each address con- 
stant for an argument contains the relative 
address of the argument. The FNCALL-IEKVFN 
subroutine enters the calling sequence into 
TXT records. 

CODE GENERATION ; Code generation converts 
text entries having operators other than 
those for statement numbers, ENTRY, CALL, 
RETURN, END, and input/output statements 
into System/3 60 machine code. To convert 
the text entry, code generation uses four 
arrays and the information in the text 
entry. The four arrays are: 

• Register array. This array is reserved 
for register and displacement 
information. 

• Directory array. This array contains 
pointers to the skeleton arrays and the 
bit-strip arrays associated with opera- 
tors in text entries that undergo code 
generation. 

• Skeleton array. A skeleton array 
exists for each type of operator in an 
intermediate text entry that is to be 
processed by code generation. The 
skeleton array for a particular opera- 
tor consists of all the machine code 
instructions, in skeleton form and in 
proper sequence, needed to convert the 
text entry containing the operator into 
machine code. These instructions are 
used in various combinations to produce 
the desired object code. (The skeleton 
arrays are shown in Appendix C. ) 

• Bit-strip array. A bit-strip array 
exists for each type of operator in a 
text entry that is to undergo code 
generation. One strip is selected for 
each conversion involving the operator. 
The bits in each strip are preset 
(either on or off) in such a fashion 
that when the strip is matched against 
the skeleton array, the strip indicates 
the combination of instructions that is 
to be used to convert the text entry. 
(The bit strip arrays are shown with 
their associated skeleton arrays in 
Appendix C. ) 

In code generation, the actual base 
registers and operational registers (i.e., 
registers in which calculations are to be 
performed), assigned by phase 20 to the 
operands of the text entry to be converted 
to machine code, are obtained from the text 
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entry and placed into the register array. 
Any displacements needed to load the base 
addresses of the operands are also placed 
into the register array. The displacements 
referred to I in this context are the dis- 
placements Of the base addresses of the 
operands from the start of the adcon table 
that contains the base addresses. These 
displacements are obtained from the infor- 
mation table entries for the operands. 
This action is taken to facilitate subse- 
quent processing. 

The operator of the text entry to be 
converted is used as an index to the direc- 
tory array. The entry in this directory 
array, which is pointed to by the operator 
index, contains pointers to the skeleton 
array and tfie bit-strip array associated 
with the operator. 

The proper bit strip is then selected 
from the bit-strip array. The selection 
depends on the status of operand 2 and 
operand 3 of the text entry. This status 
is set up by phase 20 and is indicated in 
the text entry by four bits (see Appendix 
A, "Phase 20 Intermediate Text Modifica- 
tions") : the first two bits indicate the 
status of operand 2; the second two bits 
indicate the status of operand 3. 

The status of operand 2 and/or operand 3 
can be one of the following: 

00 The operand is in main storage and 
is to^ remain there after the present 
code generation. Therefore, if the 
operand is loaded into a register 
during the present code generation, 
the contents of the register can be 
destroyed without concern for the 
operand, 

01 The operand is in main storage and 
is to: be loaded into a register. 
The operand is to remain in that 
register for a subsequent code 
generation; therefore, the contents 
of the register are not to be 
destroyed. 

10 The operand is in a register as a 
result of a previous code genera- 
tion, i After the register is used in 
the present code generation process, 
its contents can be destroyed. 

11 The operand is in a register and is 
to remain in that register for a 
subsequent code generation. The 
contents of the register are not to 
be destroyed. 

This four-bit status field is used as an 
index to select a bit strip from the bit- 
strip array associated with the operator. 
The combination of instructions indicated 



in the bit strip conforms to the operand 
status requirements: i.e., if the status 
of operand 2 is 11, the generated instruc- 
tions make use of the register containing 
operand 2 and do not destroy its contents. 
The combination, however, excludes base 
load instructions and the store into 
operand 1. 

Once the bit strip is selected, it is 
moved to a work area. The strip is modi- 
fied to include any required base load 
instructions. That is, bits are set to on 
in the appropriate positions of the bit 
strip in such a way that, when the strip is 
matched to the skeleton array, the appro- 
priate instructions for loading base 
addresses are included in the object code. 
The skeletons for these load instructions 
are part of the skeleton array. 

The code generation process determines 
whether or not the base address of operand 
2 and/or operand 3 must be loaded into a 
register by examining the status of these 
base addresses in the text entry. Such 
status is indicated by four bits: the 
first two bits indicate the status of the 
base address of operand 2; the second two 
bits indicate the status of the base 
address of operand 3. If this status field 
indicates that a base address is to be 
loaded, the appropriate bit in the bit 
strip is set to on. (The bit to be 
operated upon is known, because the format 
of the skeleton array for the operator is 
known. ) 

Before the actual match of the bit strip 
to the skeleton array takes place, the code 
generation process determines: 

• If the base address of operand 1 must 
be loaded into a register. 

• If the result produced by the actual 
machine code for the text entry is to 
be stored into operand 1. 



This information is again indicated in the 
text entry by four bits: the first two 
bits indicate the status of the base 
address of operand 1; the second two bits 
indicate whether or not a store into 
operand 1 is to be included as part of the 
object code. If the base address of 
operand 1 is to be loaded and/or if operand 
1 is to be stored into, the appropriate 
bit(s) in the bit strip is set to on. 

The bit strip is then matched against 
the skeleton array. Each skeleton instruc- 
tion corresponding to a bit that is set to 
on in the bit strip is obtained and con- 
verted to actual machine code. The opera- 
tion code of the skeleton instruction is 
modified, if necessary, to agree with the 
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mode of the operand of the instruction. 
The mode of the operand is indicated in the 
text entry. The symbolic base, index, and 
operational registers of the skeleton 
instructions are replaced by actual regis- 
ters. The base and operational registers 
to be used are contained in the register 
array. If an operand is to be indexed, the 
index register to be used is obtained. 
(The index register is saved during the 

I processing of the text entry whose third 
operand represents the actual index value 
to be used. ) The displacement of the 
operand from its base address, if needed, 
is obtained from the information table 
entry for the operand. (The contents of 

I the displacement field of the text entry 
are added to this displacement if a sub- 
script text entry is being processed. ) 
These elements are then combined into a 
machine instruction, which is entered into 
a TXT record. (If the skeleton instruction 
that is being converted to machine code is 
a base load instruction, the base address 
of the operand is obtained from the object- 

I time adcon table. The register (12) con- 
taining the address of the adcon table and 
the displacement of the operand' s base 
address from the beginning of the adcon 
table are contained in the register array. ) 



Code generation determines whether or 
not the instruction to which a branch is to 
be made is displaced less than 4096 bytes 
from an address in a reserved register by 
interrogating an indicator in the statement 
number entry for the statement number asso- 
ciated with the block containing the 
instruction to which a branch must be made. 
This indicator is set by phase 20 to 
reflect whether or not that block is dis- 
placed less than 4096 bytes from an address 
in a reserved register. 

The completion of branching optimization 
proceeds in the following manner. If a 
skeleton instruction corresponding to an on 
bit in the bit strip is a load condidate, 
it is not included as part of the instruc- 
tion sequence generated for the text entry 
under consideration. If a skeleton 
instruction corresponding to an on bit in 
the bit strip is a branch candidate, it is 
converted to an RX-format branch instruc- 
tion. The conversion is accomplished by 
replacing operand 2 (a register) of the 
branch candidate with an actual storage 
address of the format D (0,Br). D repre- 
sents the displacement of the instruction 
(to which a branch is to be made) from the 
address that is in the appropriate reserved 
register (Br) . 



Branch Processing ; The code generation 
portion of phase 25 generates the machine 
code instructions to complete branching 
optimization. The processing performed by 
code generation, if branching optimization 
is being implemented, is essentially the 
same as that performed to produce an object 
module in which branching is not optimized. 
However, before a skeleton instruction 
(corresponding to an on bit in the selected 
and modified bit strip) is assembled into a 
machine code instruction, code generation 
determines whether or not that instruction: 



• Loads into a register the address of an 
instruction to which a branch is to be 
made and which is displaced less than 
409 6 bytes from the address in a re- 
served register. ^ 



• Is an RR-format branch instruction that 
branches to an instruction that is dis- 
placed less than 4096 bytes from the 
address in a reserved register, ^ 

Note: A load candidate usually immedi- 
ately precedes a branch candidate in 
the skeleton array. 



If the instruction to which a branch is 
to be made is the first in the text block, 
both the displacement and the reserved 
register to be used for the RX-format 
branch are obtained from the statement 
number entry associated with the block con- 
taining the instruction. (This information 
is placed into the statement number entry 
during phase 20 processing.) 

If the instruction to which a branch is 
to be made is one that is subsequently to 
be included as part of the instruction 
sequence generated for the text entry under 
consideration, 3 the displacement of the 
instruction from the address in the appro- 
priate reserved register is computed and 
used as the displacement of the RX-format 
branch instruction. The reserved register 
used in such a case is the one indicated in 
the statement number entry associated with 
the block containing the text entry cur- 
rently being processed by code generation. 



RETURN STATEMEN T PROCESSING; When the 
operator of the text entry indicates a 
RETURN Statement, subroutine MAINGN-IEKTA 
passes control to subroutine RETURN-IEKTRN, 
which generates a branch to the epilogue. 



^This type of text entry is subsequently 
referred to as a load candidate. 

^This type of text entry is subsequently 
referred to as a branch candidate. 



^Skeleton arrays for certain operators con- 
tain RR format branch instructions that 
transfer control to other instructions of 
that skeleton. 
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The epilogue address is obtained from the 
save area. The address of the epilogue is 
placed into the save area during the execu- 
tion of either the subprogram main entry 
coding or the subprogram secondary entry 
coding. The address of the epilogue is 
placed into the save area during the compi- 
lation of a main program or subprogram with 
no secondary entry points (refer to the 
section "Initialization Instructions"), 



Storage Ma^ 



As a user option, subroutine lEKGMP pro- 
duces a storage map of the symbols used in 
the source program. The map contains the 
following information: 



Name Symbol 
Tag S 



Explanation 

The variable appeared to the 

left of an equal sign in the? 

source program. (stored 

into) 



ENp_STATEMENT_PROCES S ING_( CHART_2 1 ). : When 
the operator of the text entry indicates an 
END statement,^ subroutine MAINGN-IEKTA 
passes control to subroutine END-IEKUEN, 
which completes the processing of the 
module by entering the address constants 
(i.e., relative addresses) for statement 
numbers and statement numbers appearing in 
computed GO TO statements into text infor- 
mation and by generating the END record. 



subroutine END-IEKUEN calls the ENTRY- 
lEKTEN subroutine to determine whether or 
not the program being compiled is a main 
program or a subprogram and to take the 
appropriate aqtion. If it is a subprogram, 
the ENTRY- lEKTEN subroutine calls subrou- 
tine EPILOG- IfiKTEP and PROLOG-IEKTPR (see 
"Prologue and ; Epilogue Generation"). If it 
is a main program, subroutine ENTRY- lEKTEN 
generates code to call IHCFCOMH and 
generates a branch to the appropriate place 
in text. If there are secondary entry 
points, text is scanned to determine where 
they are located. An epilogue and prologue 
are generated for each entry point with a 
branch to the corresponding point in the 
object code. Subroutine ENTRY-IEKTEN 
returns control to the END-IEKUEN 
subroutine. 



Subroutine END-IEKUEN places TXT and RLD 
records in the object module for the fol- 
lowing: adcori for the save area, adcon for 
the prologue, adcon for the epilogue, adcon 
for register 12 (if needed), adcons for 
branch tables,; adcons for parameter lists, 
and adcons for 'B' block labels. The END- 
IEKUEN subroutine generates TXT information 
for each temporary. Subroutine END-IEKUEN 
calls lEND (FSD entry point) to generate 
the loader END record that must be the last 
record of the object module. Its functions 
are to signal the end of the object module 
and to inform the linkage editor of the 
size (in bytes) of the control section and 
the address of the main entry point of the 
control section. The END-IEKUEN subroutine 
then returns control to the FSD through 
subroutine MAINGN-IEKTA. 



XR 



XF 



The variable appeared to the 
right of an equal sign in the 
source program. (fetched) 

The variable was used as an 
argument. 

The variable appeared in a 
COMMON statement. 

The variable appeared in an 
EQUIVALENCE statement. 

The variable is a call-by- 
name parameter to the source 
program. 

The variable is a subroutine 
or function name. 



ASF The variable is the name of 
an arithmetic statement 
function. 

Type Identifies the type of variable — 
Type * length — in bytes. 

Add. Is the relative address of the 

variable within the object module 
(in hexadecimal). 

The total size of the object module is 
also given. 

A map of each COMMON block is generated 
to give the relative location of each vari- 
able in that COMMON block. A map of 
variables equivalenced into common is also 
provided. 

In addition, subroutine TENTXT-IEKVTN 
generates a map of statement numbers. 



P?['.9.3i2g.Ijg„^D^_lPJ-lQ'?^^ Gen eration 



Phase 2 5 generates the machine code: 
(1) to transmit parameters to a subprogram, 
and (2) to return control to the calling 
routine after execution of the subprogram. 
Parameters are transmitted to the subpro- 
gram by means of a prologue. Return is 
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made to the calling routine by means of an 
epilogue. Prologues and epilogues are pro- 
vided for subprogram secondary entry points 
as well as for the main entry point. 

Prologue: A prologue {generated by subrou- 
tine PROLOG- lEKTPR) is a series of load and 
store instructions that transmit the values 
of "call by value" parameters and the 
addresses of "call by name" parameters to 
the subprogram. (These parameters are 
explained in the publication IBM_System/3 60 

Operating S y stem; FORTRAN_IV_Lan2;ua2e, 

Form C28-6515. ) 

When subroutine PROLOG- lEKTPR generates 
a prologue, it enters the prologue into TXT 
records and inserts its relative address 
into the address constant reserved for the 
prologue address during the generation of 
initialization instructions. 

Epilogue ; An epilogue (generated by sub- 
routine EPILOG- lEKTEP) is a series of 
instructions that (1) return to the calling 
routine the values of "call by value" 
parameters (if they are stored into or used 
as arguments), (2) restore the registers of 
the calling routine, and (3) return control 
to the calling routine. (If "call by 
value" parameters do not exist, an epilogue 
consists of only those instructions 
required to restore the registers and to 
return control. ) 

When subroutine EPILOG-IEKTEP generates 
an epilogue, it enters the epilogue into 
TXT records and inserts its relative 
address into the address constant reserved 
for the epilogue address during the genera- 
tion of initialization instructions. (When 
phase 25 encounters the text representation 
of a RETURN statement, a branch to the epi- 
logue is generated. ) 



PHASE 30 



Phase 30 records appropriate messages 
(on the SYSPRINT data set) for syntactical 
errors . encountered during the processing of 
previous phases; its overall logic is illu- 
strated in Chart 22. (Table 15 shows the 
subroutines called by phase 30.) As errors 
are encountered by these phases, error 
table entries are created and placed into 
an error table. Each such entry consists 
of two parts: the first part contains 
either an internal statement number if the 
entry is for a statement that is in error, 
a dictionary pointer to a variable if the 
entry is for a variable that is in error, 
or an actual statement number if the entry 
is for an undefined statement number; the 
second part contains a message number. (If 
the error cannot be localized to a particu- 



lar statement, no internal statement number 
is entered in the error table entry. Phase 
30 simulates the internal statement number 
with a zero. ) 



Messaqe_Processing 



Using the message number in the error 
table entry multiplied by four, phase 30 
locates, within the message pointer table 
(see Appendix A, "Diagnostic Message 
Tables"), the entry corresponding to the 
message number. This message pointer table 
entry contains (1) the length of the mes- 
sage associated with the message number, 
and (2) a pointer to the text of the mes- 
sage associated with the message number. 
After phase 30 obtains the pointer to the 
message text, it constructs a parameter 
list, which consists of: 

• Either the internal statement number, 
dictionary pointer, or statement number 
appearing in the error table entry. 

• A pointer to the message text asso- 
ciated with the message number. 

• The length of the message. 

• The message number. 

• The error level. 

Having constructed the parameter list, 
phase 30 calls subroutine MSGWRT-IEKP31, 
which writes the message on the SYSPRINT 
data set. After the message is written, 
the next error table entry is obtained and 
processed as described above. 

As each error table entry is being 
processed, the error level code (either 4, 
8, or 16) associated with the message numb- 
er is obtained from the error code table 
(GRAVERR) by using the message number in 
the error table entry as an index. The 
error level code indicates the seriousness 
of the encounter error. (For explanations 
of all the messages the compiler generates, 
see the publication IBM Svstem/360 Op erat- 
ing Sy stem; FORTRAN_I V_ ,(.G_and _H ) Program- 
mer* s Guide, Form C28-6817. ) The obtained 
error level code is saved for subsequent 
use only if it is greater than the error 
level codes associated with message numbers 
appearing in previously processed error 
table entries. Thus, after all error table 
entries have been processed, the highest 
error level code (either U, 8, or 16) has 
been saved. The saved error level code is 
passed to the FSD when phase 3 processing 
is completed. This code is used as a 
return code by the scheduler to determine 
whether or not succeeding steps are to be 
executed. 
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chart 00. Compiler Control Flow 
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Chart 01. FSD Overall Logic 
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+ WITH CODE * 



* RELATIVE ♦- 

* ADDRESS * 

* ASSIGNMENT * 
***************** 



***************** 



. * EOF * . YES 

*. SWITCH .* T 

*. SET .* 

*• ■* i 

+ . .* V 



**** 

* + 

* E5 * 

* ♦ 
*♦ + * 



*****PH********** 

* REASSIGN AREA * 
*PREV. USED FOR * 

->♦ PHlO SPECIAL ♦ 

* AND NORMAL * 

* TEXT ♦ 
♦♦+*♦*♦♦*♦♦*♦♦♦♦♦ 



**** 

^ * 

» * 
**** 



GU ♦. 
.* BLOCK *. 
* DATA 
SUBPROGRAM 



GO ON 

*****nn********** 

* LPSEL-IEKPLS * 
*-*-♦-*-*-♦-*-*-* 

* ASSIGN REGS. ♦ 

* OPTIMIZE IF ♦ 

* REQUESTED * 
******i* ********* 



*****j 2* ********* 

* READ TO LjiNDL * 

* CARD IF * 
+ NECESSARY * 

* ♦ 



lOCl 

*****JH********** 

* MAINGN-IEKTA * 
*-*-*-*-*-*-*-*-* 

* BUILT ♦ 

♦ OBJECT ♦ 

♦ MODULE * 
***************** 



**** 

* 
A3 * 



K« *. 

.* ERROR *. 

.♦OR WARNING ♦. 

" . MESSAGES . * 



ENTRY POINT 
FOR END-OF-FILE 
ENCOUNTER 



ENDFILE 

****B5* ******** 

* * 

* FROM PHASE 10 ♦ 

* OR 01A3 * 
*************** 





D5 


*. 




.* IS ♦ 


YES 


* END FILE 




MISPLACED 


f 


♦ . 


1 


*. . * 


</ 


* . . * 


**** 


* NO 


♦ 






G2 ♦ 












♦ **♦ 






OUT 







r 

*♦♦♦ 

» * 

f E5 * 
f * 

**** 



****E5********* 
RETURN TO * 
CALLING t 
PROGRAM ♦ 

*************** 



*-*-*-*-*-*-*-*-* 



***************** 



Chart 02. FSD Storage Distribution 



ENTRY POINT 
FOR MAIN 
STORAGE 
REQUEST 



♦♦♦*B3 +***♦***♦ 
► FROM 1 
* REQUESTING * 
K PHASE ^ 



NO . * MAIN * 
— *. STORAGE 

♦.AVAILABLE.* 
*. . ♦ 


V *. .* 


***+♦ i 
*01 * 
* G2 + 


YES 



. * IS FREE *. 

BLOCK 

♦.AVAILABLE.* 



♦****D2********** 

* * 

* DETERMINE ♦ 

* TYPE AND * 

* AMOUNT ♦ 

* + 



***+*E2*+******** 

* * 

* CHAIN ONTO * 

* BLOCKS TO *- 

* RECOVER ♦ 

* LATER ♦ 
**♦♦♦♦+*♦♦***++♦* 



*+***E3*+^+****** 

+ CONVERT MAIN * 

♦STORAGE LIMITS ♦ 

->♦ TO SUBSCRIPTS ♦<- 

* AND STORE * 

* * 
*♦♦♦♦*♦******♦*** 



**+*F3****^*^** 
► ZERO BLOCK * 
!■ AND RETURN * 



OVERRiTE .*. 


D« *. 


. ♦ ♦. 


. * PHASE 20 *. YES 


*. CALLING .* 1 


♦ . .* 


♦. .* 1 


*. .* * 


* NO ***** 




♦ 01 * 




* G2* 




* + 




♦ 


V 


*****EH ********** 


* DETERMINE ♦ 


* AMOUNT OF * 


* PHASE 10 TEXT * 


* PROCESSED ♦ 



***************** 



MAIN + 


NO 


STORAGE 


* 1 


AVAILABLE. * 




♦. . * 




♦ . . ♦ 


V 


* 


***** 




*01 * 




♦ G2 + 
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• Table 6. FSD Subroutine Directory (Part 1 of 2) 



Subroutine 



Function 



h 



ADCON- 
lEKAAD 

AFIXPI- 

lEKAFP 

(AFIXPD* 

(FIXPD* 

(FrXPI#)* 

DCLIST- 
lEKTDC 

ERCOM- 
lEKAER 

lEKAAA 

lEKAAOO 

(ENDFILE)* 

(IEKAA9)* 

(lEKAGO* 

(lEKIORTN)* 



lEKAAOl 
(PAGEHEAD)* 

lEKATB 

lEKATM 

(PHASE)* 

(PHASS)* 

(PHAZSS)* 

(TIMERO* 

(TOUT)* 

(TSP) * 

(TST)* 

lEKFGOMH 
(IBCOM)* 
(IBCOM#)* 

lEKFIOCS 
(FIDOS)* 
(FIOCS#)* 



Internal adcon table. 



Performs exponentiation of integers, 



Prints out assembly listing of source program. 



Error message table. 



Communication table. 

Initializes compiler processing and calls the phases for execution. 
Entry point for compiler. 

IEKAA9 deletes compilation if requested. 

lEKAGC allocates and keeps track of main storage used in the construc- 
tion of the information table and for collecting text entries. 

Defines default options, DDNAMES for compiler, and page heading. 



Provides diagnostic dumps of internal text and tables. 
Timing routine. 



Controls formatted compile-time input/output. (Corresponds to 
IHCFCOMH; see Appendix E. ) 



Interface between compiler, lEKFCOMH, and QSAM. 



♦Secondary entry point 



80 



Table 6. FSD Subroutine Directory (Part 2 of 2) 

r T • " 

I Subroutine | Function 

h 



lEKTLOAD 

(ESD)* 

(lEKUND)* 

(lEKURD* 

(lEKUSD)* 

(lEKTXT)* 

(lEND)* 

(RLD) * 

(TXT) * 

PUTOUT- 

lEKAPT 

(PUTOUT)* 



Builds ESD, TXT, RLD, and loader END records. 



i Maximizing service routine for integers and reals, diagnostic trace 
ll routine; bypasses lEKFCOMH for some error messages. 



]. .__i 

I * Secondary entry point 
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chart 03. Phase 10 Overall Logic 



ENTRY IS TO 
DISPATCHER 
(lEKCIN). 
lEKCIN 

****A1* ******** 

* FROM * 

* FSD * 

* 4 



****+;^2********** 

* * 

* * 

>* INITIALIZE * 

* * 

* ♦ 

* * 

* B2 *-: 

**♦♦ 

\? 

♦****B2*****+**** 

* GETCD-IEKCGC * 
*-♦-*-*-*-*-♦-*-* 
♦READ, LIST, AND ♦- 
♦PREPARE SOURCE * 

* ST+TEMENO * 



NOTE : 

DISPATCHER (DISPTCH-IEKCDP) , 
IS WITHIN DOTTED LINES. 
DSPTCH-IEKCDP CALLS THE 
PREPARATORY SUBROUTINE 



*****B3******+*** 

* XCLASS-IEKDCL * 
+-♦-♦_♦_♦_♦_*_*_♦ 

->* PROCESS STATE- * 

* MENT NUMBER * 

* (IF PRESENT) ♦ 
***************** 



*****Q2*********-1 

* DETERMINE ■> 

* ROUTE FROM 1 
♦CLASSIFICATION t 

* CODE -t 

* 4 
****************,t 



SEE TABLE 8 FOR A 
DESCRIPTION OF THE 
SUBROUTINES OF 
PHASE 10. 



+ + 

* PROCESS + 

* SOURCE ♦ 

* STATEMENT * 

* + 
***************** 



SEE TABLE 7 



****Elt ********* 
► TO PHASE 15 1 
!■ VIA FSD * 
K i 

******* *******t 



NO 

**** 

* * 
->* B2 ♦ 

* + 
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Chart 04. Subroutine STALL- lEKGST 



+ * + *A2** + * + *'t 
!■ FROM FSD 
* CHART 01 

************* 



V 
***++B2********** 

* lEKTLOAD * 
+-*-*-♦-*-*-*-+-* 

* GENERATE * 

* ENTRY CODE * 

* * 
***************** 



, ♦ ANY * , 

LITEriAL 

CONSTANTS 



+-*-*-*-*-*-*-+- 



*************** 



+ SET * 
+ UP SPACE FOR * 
* SAVE AREA AND 
+ BRANCri TABLES + 
+ 
**************** 



D2 *. 

. * ANY * , 

I ♦UNFINISHED * 

, EQUIVALENCE 



***+*D3**+++****+ 
+ ♦ 

♦COMPUTE OFF-SET* 
>* FOR UNFIN. * 
* EQUIV ENTRIES * 

***************** 



♦RESET POINTERS ♦ 
->*FOR EACH CHAIN *<- 
+ OF TARLE * 
* ENTRIES * 
***************** 



* ANY * 

COMPLEX 

ITEMS 

IN CHAIN 



. ♦ ALL + . 
NO . ♦ TABLE 

+. CHAINS 

+. PROCESSED. 



ANY 
UNDEFINED 
.STMT. NOS. 



*****P2** ******** 

♦ GENERATE ♦ 

♦ AND CHAIN ♦ 
>♦ IMAGINARY * 

♦ PORTIONS INTO ♦ 

♦ TABLE ♦ 
***************** 



G2 ♦. 
0PT=2 



* * 

* SET ♦ 
>♦ UP ERROR ♦ 

+ MESSAGE ♦ 

+ * 



>♦ ASSIGN ♦ 
* COORDINATES ♦ 
♦BASED ON USAGE ♦ 
***+*♦*****♦***** 



*****J1********** 

* * 

* COMPUTE * 

♦ OFF- SETS AMD * 

♦ GROUP HEADS * 

++**♦♦*+*+***++++ 



ANY COMMON 



*****^j********** 

* COMPUTE * 

♦ DISPLACEMENT ♦ 
->^AND ENTRY BLOCK* 

+ POINTERS + 



y***********:i 



!■* + * 



V 

♦♦♦♦Kl**^+****+ 
^ RETURN * 
!■ TO FSD « 
•■ CHART 01 * 

*********** **** 
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Table 7. Phase 10 Source Statement Processing 



T T 

Main Processing 
Subroutine 



Statement Type 



Subroutines Used 



ARITHMETIC 



XARITH-IEKCAR 



lEKCCR, 
IEKCS2 



lEKCDP, lEKCGW, lEKCPX, lEKCSl, 



STATEMENT 
FUNCTION 



DSPTCH-IEKCDP 
XARITH-IEKCAR 



lEKCCR, 
IEKCS2 



lEKCDP, lEKCGW, lEKCPX, lEKCSl, 



H 



DIMENSION, 

EQUIVALENCE, 

COMMON 



XSPECS-IEKCSP 



lEKCCR, 
IEKCS3 



lEKCDP, lEKCGW, lEKCLC, lEKCSl, IEKCS2, 



EXTERNAL 



DSPTCH-IEKCDP 
XDATA-IEKCDT 



lEKCGW, IEKCS3 



TYPE, DATA 



I-— - 



lEKCGW, lEKCLC, lEKCDP, lEKCCR, lEKCPX, 
IEKCS3, lEKCSP, IEKCS2 



DO 



XDO-IEKCDO 



lEKCGW, 
IEKCS2, 



lEKCDP, lEKCLT, IEKCS3, lEKCCR, 
lEKCPX 



SUBROUTINE, CALL 
ENTRY, FUNCTION 



XSUBPG-IEKCSR 



lEKCGW, 
lEKCPX 



lEKCDP, IEKCS3, lEKCLC, lEKCLT 



READ, WRITE, 
PRINT, PUNCH, 
FIND 



XIOOP-IEKCIO 



lEKCAR, lEKCCS, lEKCDP, lEKCGW, lEKCLT, 
lEKCPX, lEKCSl, IEKCS2, IEKCS3 



1- 



DEFINE, 
DEFINE FILE, 
IMPLICIT, 
STRUCTURE, 
NAMELIST 



XTNDED-IEKCTN 



lEKCGW, lEKCDP, lEKCCR, lEKCSl, lEKCLC, 
IEKCS2, lEKCPX, IEKCS3 



BACKSPACE, 
REWIND, 
END FILE, 
RETURN, ASSIGN,. 
FORMAT, PAUSE, 
STOP, END 



XIOPST-IEKDIO 



lEKCGW, 
IEKCS2, 



lEKCDP, lEKCPX, lEKCCR, lEKCLT, 
IEKCS3 



IF, CONTINUE, 
BLOCK DATA 
j. 

I GO TO 

L 



DSPTCH-IEKCDP 



lEKCPX 



I XGO- lEKCGO 



I lEKCDP, 
-X 



lEKCGW, lEKCLT, lEKCPX, IEKCS3 
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• Table 8. Phase 10 Subroutine Directory (Part 1 of 

r T T 

I Subroutine J Type 1 

|. ^__^ 4- 



3) 



Function 



CSORN-IEKCCR J Utility (collection, conversion, 

(lEKCLO* ] entry placement) 

(lEKCSD* i 

(IEKCS2)* ] 

(IEKCS3)* } 



DSPTCH-IEKCDP] Dispatcher, Keyword, and 
(lEKCIN)* I Utility (entry placement) 



1 

FORMAT-IEKTFM I Miscellaneous 



GETCD-IEKCGC | Preparatory 
(lEKAREAD)* | 



GETWD-IEKCGW j Utility (collection) 



lEKKOS 



i Utility (table entry) 



Secondary entry point lEKCCR directs the 
entering of variables and constants into 
information table 

Secondary entry point lEKCLC converts 
integer, real, and complex constants to 
their binary equivalents. 

Secondary entry point lEKCSl places 
variable names on full word boundaries 
for comparison to other variable names. 

Secondary entry point IEKCS2 places dic- 
tionary entries constructed for 
variables and constants of the source 
module into. the information table. 

Secondary entry point IEKCS3 combines 
the functions of entries lEKCSl and 
IEKCS2 (above) for variable names. 

Controls phase 10 processing, passes 
control to the preparatory subroutine to 
prepare the source statement, determines 
from the code assigned to the statement 
which subroutine is to continue process- 
ing the statement, and passes control to 
that subroutine. 

Develops intermediate text representa- 
tions of the BLOCK DATA, CONTINUE, 
EXTERNAL, and IF statements and that 
portion of a statement function to the 
left of the equal sign; builds informa- 
tion table entries for the operands of 
these statements; and analyzes these 
statements for syntactical errors. 

Builds error table entries for the syn- 
tactical errors detected by phase 10 and 
places them in the error table. 

lEKCIN is the initial entry point to 
lEKCDP. 

Generates format text from phase 10 
intermediate text. 

Reads, lists (if requested), packs, and 
classifies each source statement. 

lEKAREAD is a secondary entry point to 
lEKCGC. 

Obtains the next group of characters in 
the source statement being processed. 

Assigns coordinates based on usage count 
to variables and constants. 



}. i 

I ♦Secondary entry point 

L 
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• Table 8. Phase 10 Subroutine Directory (Part 2 of 3) 

r T T 

I Subroutine | Type | 



Function 



h- 



lEKXRS 
LABTLU-IEKCLT 

PHIO-IEKCAA 
PUTX-IEKCPX 



STALL- lEKGST 



Miscellaneous 

Utility (entry placement) 

Utility (coitiinon data area) 
Utility (entry placement) 



Utility (table entry and text 
generation) 



I XARITH-IEKCAR 1 Arithmetic 



XCLASS-IEKDCL) Utility (text generation) 



XDATYP-IEKCDT I Keyword (table entry and text 

generation) 



XDO-IEKCDO [Keyword (table entry and text 

generation) 



Writes XREF buffer on SYSUT2. 

Places statement number entries into the 
information table. 

Phase 10 COMMON area. 

Places text entries into the appropriate 
subblocks, obtains the next operator 
from the source statement, and places 
the operator in the text entry work 
area. 

Generates entry code for object module, 
calls lEKTFM to translate format text to 
object code, generates object code for 
literal data text, processes equivalence 
entries (those that were equivalenced 
before being dimensioned) , sets aside 
space in the object module for the pro- 
blem program save area and for computed 
I GO TO branch tables, checks for unde- 
fined statement numbers, ^jrechains 
variables, assigns coordinates based on 
usage count, processes COMMON entries, 
and processes EQUIVALENCE entries. 

Controls the processing of arithmetic 
statements, CALL arguments, expressions 
in IF statements, I/O list items, the 
expression portion of a statement func- 
tion, and the branch tables of an arith- 
Imetic IF statement. Builds information 
table entries for the operands of the 
previously mentioned statements, and 
analyzes the statements for syntactical 
errors. 

Controls the processing of source and 
compiler-generated statement numbers, 
generates the intermediate text required 
to increment a DO index and to compare 
the index with its maximum value, and 
processes CALL argioments of the form 
Slabel . 

[Develops intermediate text representa- 
tions of DATA and TYPE statements, 
information table entries for the 
operands of DATA and TYPE statements, 
and analyzes these statements for syn- 
tactical errors. 

Develops the intermediate text and 
information table entries for the DO 
statement and implied DOs appearing in 
input/output statements and analyzes 
them for syntactical errors. 
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• Table 
r 



8. Phase 10 Subroutine Directory (Part 3 of 



3) 



Subroutine 



I" 



Type 



Function 



XGO-IEKCGO 



Keyword (table entry and text 
generation) 



XIOOP-IEKCIO 



Keyword (table entry and text 
generation) 



XREF-IEKXRF ] Miscellaneous 



XSPECS-IEKCSPJ Keyword (table entry) 



XSUBPG-IEKCSR I Keyword (table entry and text 

generation) 



XTNDED-IEKCTNa Keyword (table entry and text 

generation) 



XIOPST-IEKDIOl Keyword (table entry and text 

generation) 



Develops intermediate text representa- 
tions of the GO TO (unconditional, 
I assigned, and computed) statements, con- 
structs information table entries for 
the operands of these statements, and 
analyzes these statements for syntactic- 
al errors. 

Develops intermediate text representa- 
tions of input/output statements, con- 
structs information table entries for 
their operands, and analyzes input/ 
output statements for syntactical 
errors. (I/O list items are processed 
by subroutine XARITH-IEKCAR. > 

Reads in XREF buffer from SYSUT2. 
Prints out a cross-reference listing 
directly after the source listing. 

Constructs information table entries for 
variables and arrays appearing in COM- 
MON, DIMENSION, and EQUIVALENCE state- 
ments and analyzes these statements for 
syntactical errors. 

Develops intermediate text representa- 
tions of CALL, SUBROUTINE, ENTRY, and 
FUNCTION Statements; constructs informa- 
tion table entries for the operands of 
these statements; and analyzes these 
statements for syntactical errors. 
(This subroutine passes control to sub- 
routine XARITH-IEKCAR to process the 
arguments appearing in CALL statements. ) 

Develops intermediate text for NAMELIST 
and DEFINE FILE statements ; constructs 
information table entries for variables 
[and arrays appearing in the NAMELIST, 
DEFINE FILE, and STRUCTURE statements; 
resets the implicit mode table according 
to the specification of the IMPLICIT 
statement; and analyzes these statements 
for syntactical errors. 

[Develops intermediate text representa- 
tions of ASSIGN, RETURN, FORMAT, PAUSE, 
BACKSPACE, REWIND, END FILE, STOP, and 
END Statements; constructs information 
table entries for the operands of the 
ASSIGN, BACKSPACE, REWIND, and END FILE 
statements; and for the operands (if 
any) of the RETURN, PAUSE, and STOP 
statements; and analyzes all of these 
statements for syntactical errors. 
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chart 05. Phase 15 Overall Logic 



**♦* A3 ***♦*♦♦*♦ 

► FROM FSD * 

► CHART 00 ■• 
t i 

4i ************* * 



SEE TABLE 9 FOR A 
BRIEF DESCRIPTION 
OF THE SUBROUTINES 
OF PHASE 15. 



*-♦-*-*-*-*-*-♦- 

* PHOCESS 

* PHASE 10 

* TEXT 



.*-♦-*-*-♦-*-♦-* 

RELATIVE ' 

ADDRESS * 

ASSIGNMENT * 



* TO PHASE * 
► 20 VIA FSD * 

M 4 
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Chart 06. PHAZ15 Overall Logic 



FROM FSD ♦ 
CHART 01 * 



♦****B2**+******* 

* INITIALIZE ♦ 

* * 



***C2********** 



♦ ♦ GET A PHASE 
C2 ♦ >+ 10 TEXT 

* ♦ ENTRY 
»*♦♦ * 



D2 ♦. 
.♦STATE- ♦. 
*MENT NUMBER*. 
TEXT ENTRY . 



100 08B2 

**+**El* ♦♦*♦♦*♦*♦ 

* GENER-IEKLGM ♦ 
*-♦-*-*-*-*-*-*-* 

* OUTPUT ♦< 

* END * 

* STATEMENT ♦ 



YES .,* IS 

.+, *. OPERATOR 

*. END 



, *ARITHMETIC * . YES 

, TRANSLATION .* 

* . NEEDED . * 



*****D3********** 

* INDICATE IF ♦ 

* STATEMENT * 
>* NUMBER IS *- 

*POR ENTRY POINT* 

* * 
***+**♦♦*♦♦♦»**** 



08B2 
****»D'(********** 

* GENER-IEKLGN * 

>* CREATE NEW * 

* TEXT BLOCK * 

* * 



**** 

* i 

* C2 « 



07 

* ALTRAN-IEKJAL * 
*_*-♦_♦_*_ ♦-#_♦_» 

->* PERFORM ♦- 

* ARITHMETIC * 

* TRANSLATION * 



♦ ♦♦* 

* * 
->* C2 ♦ 

* 4 
»*♦♦ 



►♦***H1 ♦***♦*♦♦*♦ 



^*^l*^,<HL**^ 



♦♦**J1********* 
^ TO CORAL * 
* VIA FSD » 

!■ i 



PROC- 
ESSING 
, NEEDED 
*. . * 



08B2 
****4<H2********** 

* GENER-IEKLGN * 
*-♦-*-*-*-+-♦-*-* 

* PASS ON * 

* PHASE 10 ♦ 

* TEXT ENTRY * 
***************** 



*****G3********** 

* * 

* PROCESS * 
>♦ TEXT * 

* ENTRY * 

* * 
tlt^i^Hi ****** ******* 



08B2 
*****H3********** 

* GENER-IEKLGN * 
*-*-♦-*-*-♦-*-*-* 

* COMPLETE TEXT * 

* ENTRY OUTPUT ♦ 

* TEXT ENTRY * 
***************** 
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• Chart 07. ALTRAN-IEKJAL Control Flow 



ALTRAN - lEKJAL 

L_ 



Piimary 
Adiecrive Code 

I 



ItiKJR 



Function 
References 



lEKJDF 
(lEKKPR)" 



Arithmetic 
Operators 



lEKLOK 




lEKKUN 
(lEKJEX)* 



Subscript 
Operators 



lEKKPA 



lEKJCP 



(lEKJMO)* 




lEKKSA 



Relational 
Operators 



lEKKRE 



lEKKSM 



Logical 
Operators 



lEKJAN 
(lEKKNO)* 



lEKJGR 



*Secondary entry point of routine immediately above 



lEKLGN 



NOTE: The logic and flow of the arithmetic translator is too complex to be represented on one or two conventional flowcharts. Chart 07 indicates 
the relationship between the arithmetic translator (subroutine ALTRAN) and its lower-level subroutines. An arrow flowing between two 
subroutines indicates that the subroutine at the origin of the arrow may, in the course of its processing, call the subroutine indicated by 
the arrowhead. In some cases, a subroutine called by ALTRAN may, in turn, call one or more subroutines to assist in the performance of 
its function. The level and sequence of subroutines is indicated by the lines and arrowheads. 

In reality, ail of the pathways shown connecting subroutines are two-way; however, to simplify the chart, only forward flow has been 
indicated by the arrowheads. .All of the subroutines return control to the subroutine that called them when they complete their processing. 
(If a subroutine detects an error serious enough to warrant the deletion of the compilation, the subroutine passes control to the FSD, rather 
than return control to the subroutine that called it.) 

The specific functions of each of the subroutines associated with the arithmetic translator are given in the subroutine directory following 
the charts for phase 15. 
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Chart 08. GENER-IEKLGN Text Generation 



GE.NER-IEKLGN 

****Pi2********* 

* FROK * 

* CALLING * 

* ROUTINE * 
***++*♦♦*♦+♦**♦ 



* + 
+ * 

* INITIALIZE * 

* ♦ 

* * 



* GET STORAGli * 

* FOR NEW * 

* TEXT ENTRY * 

* ♦ 



.* OPERATOR 
PHASE 15 
* . ITEK 



* * 

* PASS ON * 
>* PHASE 10 *- 

* TEXT ENTRY ♦ 

* * 



♦****D4 **♦♦***♦** 

* Sr,T TEXT ♦ 

* CHAIN, BLOCK * 
>* SIZE, AND *- 

* BLOCK END ♦ 

* ♦ 
***************** 



STATEMENT 
NUKBER 
. TEXT 



*-♦_*_♦_*_*_*_+_♦ 
>* RECORD 

* CONNECTION 

* INFORMATION + * 
***************** 



>* D5 + 



♦TXTLAB-IEKLAB RECORDS 
FALL-THROUGH CONNECTIONS 
AND SETS UP STATEMENT 
NUMBER TEXT ENTRIES. 



V 
*****P2********** 

* TXTREG-IEKLRG * 
*-*-*-♦-*-♦-♦-*-* 

* PROCESS ♦ 

* REGULAR * 

* TEXT ENTRY ** * 
+**♦♦++*++++*♦+** 



*****Q2* ********* 

* SET TEXT * 

* CHAIN, BLOCK ♦ 
+ SIZE, AND ♦ 

* BLOCK END 

*♦♦♦*♦♦♦*♦*+****♦ 



**TXTREG-IEKLRG RECORDS CONNECTION 
INFORMATION, OBTAINS DICTIONARY 
SPACE FOR TEMPORARIES AND UP- 
DATES MVS, MVF, AND MVX (VIA A CALL TO 
SUBROUTINE MATE-IEKLMA) . 
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chart 09. CORAL Overall Logic 



CORRL-IEKGCR 

♦ FROM FSD 

* CHART 01 



***♦♦**< 



►*+**+* 



►♦♦**C1********** 

* ASSIGN * 

* RELATIVE * 

•■ ADDRESSES TO *<- 
► CONSTANTS * 

¥ * 

(■ + *+*** + + ♦♦ + *♦ + ** 



V 
**++*Dl ********** 

* ASSIGN * 

* RELATIVE * 

* ADDRESSES TO *<- 
* LOCAL VARIABLES* 

* * 
**+*+♦**+*♦*****» 



.* ANY *. 
.* COMMON OR *. YES 
*. EQUIVALENCE .* 



++***F1******+*** 

* * 

* PROCESS * 

* EXTERNAL *< 

* REFERENCES * 

* * 
+++**++♦***♦+*+** 



V 
Hi" ■*. 



♦***K1********* 
^ TO FSD * 

► CHART 01 ' 
I" * 

++****♦*******+ 



OPERATIONS WITHIN 
DOTTED LINES ARE 
PERFORMED BY 
CORAL- lEKGCR 



*****B2********** 

* NDATA-IEKGDA * 
♦-*-*-*-*-+-*-*-* 

->* PROCESS PHASE * 

♦ 10 DATA TEXT * 
+ * 



*-+-*-*-*-♦-*-*- 

->*GENERATE TEXT/ 

* ADCONS FOR 

* OEJ, MOD. 

4>4:4:t***********4 



V 

***+*D2**+******* 

* lEKGCZ * 
*-*-♦-*-*-*-*-*-* 

->* COMPUTE BASE *< 

* AND DISPLACE- * 

* KENT * 

4: + *«**4'********** 



****+E2********** 

* EQVAR-IEKGEV * 
*-*-*-*-*-*-+-*-* 

->*ASSIGN REL ADDR* 
*T0 COKMON/EQUIV* 

* VARIABLES ♦ 
♦+***♦+**♦+*♦*+♦* 



->* PROCESS NAME 
*LIST AND GENER- 
*ATE DICTIONARY 



*****H2********** 
+ DATOUT-IEKTDT * 
+ -*-♦-*-*-+-*-*-* 
>* PROCESS DATA 
+ AND GENERATJi ♦ 
* CONSTANTS * 
*++******+**♦***♦ 



*-*-+-+-*-+-*-*- 
>+ PROCESS DEF 

♦ FILE AND 

* GENERATE TEXT 
+♦♦***+♦♦++**♦** 



-*-+_*-*-♦-♦_*-♦ 



*< >* 



k*********** 
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Table 9. Phase 15 Subroutine Directory (Part 1 of 2) 

r "-T T • 

Associated 
.Phase 15 
Subroutine \ Segment | Function 



ALTRAN-IEKJAL 



ANDOR-IEKJAN 
(lEKKNO)* 



BLTNFN-IEKJBF 



CNSTCV-IEKKCN 



CORAL- lEKGCR 



CMSIZE-IEKGCZ 



CPLTST-IEKJCP 
(lEKJMO)* 



DATOUT-IEKTDT 



DFILE-IEKTDF 



DFUNCT-IEKJDF 
(lEKKPR)* 



DUMP15-IEKLER 

EQVAR-IEKGEV 

FINISH-IEKJFI 

FUNRDY-IEKJFU 

GENER-IEKLGN 



PHAZ15 
(5) 

PHAZ15 
(5) 



PHAZ15 
(5) 



PHAZ15 
(5) 

CORAL 
(6) 



CORAL 
(6) 



PHAZ15 
(5) 



CORAL 
(6) 

CORAL 
(6) 

PHAZ15 
(5) 



PHAZ15 
(5) 

CORAL 
(6) 

PHAZ15 
(5) 

PHAZ15 
(5) 

PHAZ15 
(5) 



GENRTN-IEKJGR j PHAZ15 
\ (5) 

_x 



Controls the arithmetic translation process. 



Checks the mode of the arguments passed to it, decomposes IF 
statements, and generates text entries for AND and OR 
operations. 

Generates phase 15 text for in-line functions by either 
expanding the function or creating a phase 15 text item 
(which is expanded by phase 25), 

Performs compile time conversion of constants. 



Controls the flow of space allocation for variables, 
constants, and adcons necessary for local variables, COMMON, 
EQUIVALENCE, and external references; processes constants, 
local variables, and external references. 

Keeps track of space being allocated; generates adcons for 
address computation; rechains data text, generates adcons for 
COMMON, EQUIVALENCE, and external references; and sets up 
error table entries for phase 30. 

Checks the mode of the operands in an arithmetic triplet mak- 
ing adjustments where necessary and controls text generation 
for the triplet. 

Puts phase 15 data text into object module. 



Processes define file text. 



Determines if a reference is to an in-line, library, or ex- 
ternal function, and determines the validity df arguments to 
the subprogram; inserts the appropriate function operator 
into phase 15 text and builds the parameter list in the adcon 
table and in text for the subprogram referred to; performs 
parameter list optimization. 

Records errors detected during PHAZ15 processing. 



Handles COMMON and EQUIVALENCE space allocation. 



Completes the processing required for a statement when its 
primary adjective code is forced from the pushdown table. 

Creates pushdown entries for references to implicit library 
functions. 

Generates phase 15 text consisting of unchanged phase 10 
text, phase 15 standard text, and phase 15 statement number 
text. 

Builds appropriate phase 15 text entries for simple items 
forced from the pushdown table. 



I 1 *Secondary entry point 
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• Table 9, Phase 15 Subroutine Directory (Part 2 of 2) 

r T T 

1 Associated 
Phase 15 
Segment 



Subroutine 



Function 



LOOKER- lEKLOK 



MATE-IEKLMA 



NDATA-IEKGDA 



NLIST-IEKTNL 



OPICHK-IEKKOP 
(lEKKNG)* 



PAREN-IEKKPA 



PHAZ15-IEKJA 



RELOPS-IEKKRE 



STTEST-IEKKST 



SUBADD-IEKKSA 



SUBMLT-IEKKSM 



TXTLAB-IEKLAB 



TXTREG-IEKLRG 



UNARY- lEKKUN 

(lEKKSW)* 

(lEKJEX)* 



PHAZ15 
(5) 



PHAZ15 
(5) 



CORAL 
(6) 



CORAL 
(6) 



PHAZ15 
(5) 



PHAZ15 
(5) 



PHAZ15 
(5) 



PHAZ15 
(5) 



PHAZ15 
(5) 



PHAZ15 
(5) 



PHAZ15 
(5) 



PHAZ15 
(5) 

PHAZ15 
(5) 

PHAZ15 
(5) 



Searches the function table (lEKLTB) to determine if a given 
function is FORTRAN supplied. 



Records usage information in the MVS, MVF, and MVX fields if 
one of the optimizer paths through phase 20 is selected. 



Converts phase 10 data text to phase 15 data text. 



Processes namelist text. 



Determines whether or not operand 1 should be a temporary 
and checks for negative arguments. 



Removes the ( or -( from the pushdown table when the corre- 
sponding ) is encountered. 



Controlling routine of PHAZ15. Determines if the phase 10 
text for a statement needs arithmetic translation. If so, 
ALTRAN-IEKJAL is called. Otherwise GENER-IEKLGN is called to 
put out unchanged phase 10 text. Builds CMAJOR if 0PT=2. 



Calls siibroutine GENER-IEKLGN to generate text entries for 
relational operators. (Output may be either a relational or 
branch operation, ) 



Builds text for replacement statements [e.g., A=B, A=B(I), 
A(I)=B, A(I)=B(I) ], 



Generates text to add the terms in a subscript computation, 
determines if a subscript text entry in the pushdown table 
should be entered into phase 15 text, and calls subroutine 
GENER-IEKLGN to generate the text entry when appropriate. 



Generates the text to multiply the first term of a subscript 
computation by its associated length factor, or, in the case 
of variable dimension, to multiply the nth dimension by 
length. 

Processes statement number text entries for subroutine 
GENER-IEKLGN and creates entries in RMAJOR. 

Processes standard phase 15 text entries for subroutine 
GENER-IEKLGN and makes RMAJOR entries. 

Optimizes arithmetic t;:iplets and processes the exponentia- 
tion operator. 



|. X 

I ♦Secondary entry points, 

L 
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• Table 10. Phase 15 COMMON Areas 



I j Name 



1- 



I Function 



lEKGAl 

PH15-IEKJA1 

CMAJ0R-IEKJA2 

IEKJA3 

RMAJ0R-IEKJA4 

lEKLTB 



CORAL COMMON data area. 
Phase 15 COMMON data area. 
Backward connection table. 
Function information tables. 
Forward connection table. 
Function table COMMON area. 
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• Chart 10. Phase 20 Overall Ld^ic 



LPSiL-IEKPLS 



****A1 ♦*♦***♦** 
f FROI'; FSD * 
• CHAIN 01 * 

*************** 



SEE TABLE 12 FOR A BRIEF 
DESCRIPTION OF THE NAJOR 
SUBROUTINES OF PHASE 20. 



CI *. 

* 

OPT=0 



__- * OBTAIN FIRST ♦ 
. * >♦ (NEXT) BLOCK *- 



***************** 



*****C3********** 

* SSTAT-IEKRSS ♦ 
*-*-♦-*-♦-♦-♦-*-* 

>* SET STATUS »- 

* AND ASSIGN ♦ 

* REGISTERS ♦ 
***************** 



**** 

* * 

* C5 *— 

* ♦ 
**** 

LO 

****C5* ******** 

* * 
>* TO PSD * 

* CHART 01 ■* 
*************** 



*****SX* ********* 

* * 
♦INITIALIZE FOR * 

* OPTIMIZED * 

* REGISTER - * 

* ASSIGNMENT ♦ 
***************** 



**** 
* 
J3 * 

* 
**** 



*****ti±**** ****** 

* * 

* INCREMENT * 

* LOOP NUMBER *< 

* PARAMETER * 

* * 
***************** 



*****02********** 

♦ TOPO-IEKPO ♦ 

♦ -♦-*-♦-♦-♦- «- ♦- ♦ 
>* DETERMINE *< 

♦BACK DOMINATORS+ 

♦ FOR BLOCKS ♦ 
***************** 



*****E2*** ******* 

* BIZX-IEKPZ " 
*-*-*-*-*-*-*-*-* 

* DETERMINE * 

* BUSY-ON-EXIT » 

* DATA * 
***************** 



Jl ♦. 




PRO- ♦ . 




ChSSING ♦ 


REG 


TEXT OR 




REGS . . ♦ 




. ♦ 




♦ . .♦ 


1 


♦ TEXT 


*♦♦♦ 


1 


* 


1 


♦ K5 


<1 


♦ 


**** 


**** 



♦♦♦♦♦H2***+++++** 

♦ * 

♦ MARK BLOCKS ♦ 
-* IN LOOP ♦< 

♦ COMPLETED ♦ 

♦ * 
*************t*** 



2000 

♦♦♦♦♦J2^*^^*^^^^* 

♦ BLS-IEKSBS ♦ 
(*-*-*-♦-*-*-♦-♦-» 

+ COMPUTE BLOCK ♦<- 

♦ SIZE, DET. RX ♦ 

♦ BRANCHES ♦ 
*************tt^** 



**** 

* * 
->* C5 1 

* * 
**** 



*****r}j** ******** 
* BAKT-IEKPB ♦ 
♦-♦-*-»-*-♦-♦-♦-• 
->^DETERMINE BACK ♦ 
♦TARGET AND LOOP* 
♦NUMBR FOR BLKS * 
***************** 



*****E3*** ******* 



♦ SET LOOP ♦ 
>♦ NUMBER ♦ 

♦ PARAMETER ♦ 

♦ TO 1 ♦ 
***************** 


**** 


* * 

* F3 *-> 

* * 




**** 





*****1'2*** ******* 

* TARGET- I EKPT ♦ 
*-♦-♦_»_«-♦_♦_♦-♦ 

* SELECT LOOP. ♦ 

♦ GET BACK TAR- ♦ 

♦ GET OF LOOP ♦ 
***************** 



V llBl 

♦♦♦♦♦G3***^*^^^** 

♦ XPELIM-IEKQXM ♦ 
*-♦-*-•-*-♦-•-♦-♦ 

* COMMON *- 

♦ EXPRESSION ♦ 

♦ ELIMINATION ♦ 
***************** 

**** 

* * 

* H3 ♦ — -I 



• * J 

♦ *** V 



**** 




* * 




* J3 •- 


> 


* * 




**** 




205 





YES .♦ REGISTER ♦. NO 

♦. ASSIGNMENT .* 

♦.COMPLETED. ♦ 



1462 

♦♦♦♦♦K3^^^^^**^^* 

♦ REGAS-IEKRRG ♦ 
♦-♦-♦-*-♦-«-♦-♦-♦ 

♦ FULL ♦< 

♦ REGISTER ♦ 

♦ ASSIGNMENT ♦ 
♦♦**♦♦♦♦♦♦♦♦♦**♦♦ 



*****tiH********** 

♦ REDUCE- lEKQSR ♦ 
♦-*-♦-♦-♦-*-♦-♦-* 

-♦ STRENGTH ♦< 

♦ REDUCTION ♦ 

♦ * 
***************** 



. * COMPLETE- ♦ . YES 

. OPTIMIZED .♦ 

♦ . PATH . ♦ 



I NO **** 

* * 
!■->♦ K5 ♦ 

♦ ♦ 
♦ ♦♦♦ 



->♦ 



12A2 
♦♦♦♦♦G5+ ♦*♦♦♦♦♦♦♦ 
♦ BACMOV-IEKQBM ♦ 

BACKWARD ♦ 
MOVEMENT * 

t** ************ 



\i****j$* ********* 

!■ SET LOOP ♦ 

> NUMBER * 
" PARAMETER ♦ 

► TO 1 ♦ 
\i**************** 



**** 



V 



♦♦♦♦♦K5+++++^+^^* 

♦ TARGET- lEKPT ♦ 
♦-*-♦-♦-*-♦-♦-*-♦ 

-♦ SELECT LOOP. ♦ 

♦ GET BACK TAR- ♦ 

♦ GET OF LOOP ♦ 
***************** 



**** 
* * 

•>* H3 ♦ 
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chart 11. Common Expression Elimination (XPELIM-IEKQXM) 



XPELIM-IEKQXM 

* FROM * 

* LPSEL-IEKPLS * 

* CHART 10 t 
*************** 



*****1^1********** 

* * 

* GET ♦ 

* FIRST *' 

* BLOCK * 

* * 
***************** 



******** 



I->*NEXT TEXT ENTRY*< 
♦ ♦ 

♦ ♦ 

***************** 
** A 



♦ Dl * 

♦ ♦ 
**** 



* GET FIRST ♦ 
->* TEXT ENTRY I.M ♦ 

* BLOCK ♦ 

* * 
***************** 



*.END OF BLOCK . *- 



♦ END ♦ , 

OF ♦. YES 

CURRENT . * 

LOOP . ♦ 



****C5********* 

* TO 1 
•■ LPSEL-IEKPLS 1 

* CHART 10 < 
*************** 



***************** 



20C 
NO . 



.♦SEE TABLE 11 



BASIC 
CRITERIA 

MET 
*. . ♦ 



. YES * SCAN FOR * 
. * >* LOCAL COMMON * 

* TEXT ENTRY ♦ 

* ♦ 
***************** 



**** 

* * 

* E2 * — 

* * 
♦ *♦* 

)0 
*****E2** ******** 

* * 

* GET FIRST ♦ 

* (NEXT) BACK *< 

* DOMINATOR ♦ 

* » 
***************** 



YES . * END ♦ . 

♦.CURRENT LOOP . 

♦. . ♦ 



E3 ♦. 

.* ♦. 

* * 

ENTRY FOUND 

*. • ♦ 

♦ . . * 

♦. . ♦ 



, YES * ELIMINATE ♦ 
, ♦ >* EXPRESSION ON ♦- 

♦ TEXT ENTRY ♦ 

♦ ♦ 
***************** 



3100 

♦**+*F3 ♦♦♦♦♦♦*♦♦♦ 

♦ GET ♦ 

♦ FIRST TEXT + 
>♦ ENTRY IN BACK ♦ 

♦ DOMINATOR ♦ 



***************** 



NO .♦ OPERANDS ♦. 

♦2+3 USED ELSE-.* 

♦.WHERE IN .♦ 
♦.LOOP .♦ 



*SEE TABLE 11 
♦ . 
*. 



**** 

* * 

* Dl ♦ 

* * 
**** 



PRIMARY ♦. YES .♦ SECONDARY 

CRITERIA .♦ >♦. CRITERIA 

MET .♦ ♦. MET 

♦ . . ♦ ♦. . ♦ 



SEE TABLE 11 



* GET NEXT TEXT ♦ 

* ENTRY IN BACK ♦ 

* DOMINATOR ♦ 

* * 
***************** 



**** 

* * 

* E2 * 

* 4 
+ ♦* + 
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• Chart 12. Backward Movement (BACMOV-IEKQBM) 



BflCl-.OV-IJiKQBM 

♦**»A1********1 
» FROM 

•> LP3EL-IEKPLS 
* CHART 10 

*************** 



♦ GET NEXT * 
» TEXT ENTRY IN ♦ 

♦ BLOCK * 

♦ ♦ 
***************** 

A 

**** 

* * 
<-♦ Cl * 

* * 
**** 

******** 



*****p,2********** 

* * 

* GET ♦ 
>* FIRST *- 

* BLOCK + 

* * 
***************** 



5100 R2 ». 

. ♦' ' * 

->*.END OF BLOCK 



ATTEKPT TO * 

PROMOTi: SPLIT *< — ■,< * 

TEMPORARIES * 



t*********** 



**** 

* * 

* C2 *-> 

**♦♦ 
2000 C2' 



.♦PROCESSING 
LIBRARY 
♦.FUNCTION . 
♦.ARCS .* 



1500 

*****Q2** ******** 

* KORAN- lEKQKO + 

YFS*-*-*-*-*-*-*-*-*NO 

VALID *■ 

ERANCH ♦ 

ITEM ♦ 

*************** 



**** 
V n 

► Dl * 

**** 



**** 
* E2 *— 
♦ ♦♦* 
3000 E2" 



* GET FIRST ♦ 
->♦ TEXT ENTRY IN ♦<- 

* BLOCK * 

* * 

*♦**♦♦♦♦♦**♦*♦*+* 



.♦PROCESSING 
->*. LIBRARY 
♦.FUNCTION . 
♦.ARGS .♦ 



. ♦ ARGUMENT 
. PROCESSING 
♦.FINISHED . 



.♦ IS THERE 
ANOTHER 
♦ . BLOCK 



♦♦♦♦B5 ♦♦♦♦♦*+♦♦ 
♦TO LPSEL-IEKPIS+ 
>♦ CHART 10 + 

* ♦ 

*************** 



FOR OPTIMIZATION CRITERIA 
FOR BACKWARD MOVEMENT, 
SEE TABLE 11. 



*♦♦* 

* * 
->* E2 * 

* * 
**** 



*** 



2200 

♦ KORAN- lEKQKO ♦ ♦♦♦♦ 
♦-♦-♦-♦-♦-♦-♦-♦-♦NO ♦ 1 

>♦ VALID BACK- ♦ >♦ Cl ♦ 

♦ WARD MOVE ♦ ♦ t 

♦ CANDIDATE ♦ ♦♦♦♦ 
♦♦♦♦♦♦♦♦♦♦+♦+♦♦♦♦ 

lYES 

♦ ♦♦* 



I— >+ El ♦ 

* ♦ 
**** 

*****E3* ********* 



aVORK ITEM 



->♦. 



*****pl********** 

* * 

* TRY TO ♦ 

* liLIMINATI-; ♦ 
» SIMPLE STOKE ♦ 

* ♦ 
***************** 



!■->* Cl * 

* 1 

**** 



MOVE TEXT ♦ 

tlNTRY TC ♦- 

aACK TARGET ♦ 

* 

*************** 



*****-^2** ******** 

* * 
♦TRY TO PEKFORK ♦ 

>♦ COMPUTATION ♦- 
♦IN BACK TARGET ♦ 

♦ * 
***************** 



*****J2* ********* 

♦ LORAN-IEKgLO ♦ 
♦-♦-♦-♦-♦-♦-♦-♦-♦ 

->♦ UPDATE VECTOR ♦- 

♦ FIELDS FOR ♦ 

♦ TEXT BLOCKS ♦ 
♦**♦♦♦*♦*♦♦♦♦*♦♦♦ 



>^POINTER TO TEXT^ ■, 

* ENTRY ♦ 

* ♦ J 

♦♦♦♦♦♦♦♦♦♦♦♦♦♦**♦ V 



*f2********** 




F3 


* . 




9000 F« ♦. 






♦ ♦. 






. ♦ ♦. 


OPERANDS ♦ 


,* 


PRIMARY ♦. NO 






♦PROCESSING ♦. YES 


2 AND 3 ♦ 


>♦. 


CRITERIA .♦ 


_. 


->♦ 


LIBRARY . ♦ 1 


COMBINED ♦ 


♦ 


MET .♦ 






♦.FUNCTION .♦ 






♦ . .♦ 






♦.ARGS .♦ 


************* 




♦ . . ♦ 

♦ YES 






♦ . .♦ V 
♦ NO ♦*♦♦ 














1 *♦♦♦ ♦ 














1 ♦ ^+02 














L->* Dl ♦ ♦ 














* ♦ *♦♦* 






V 






♦ ♦♦* 




4000 


G3 ♦. 
.♦ ♦. 










.♦ 


LIBRARY ♦. YES 










♦ . 


FUNCTION . ♦ 1 










* 


ARGUMENT .♦ 
♦. . ♦ 

♦. .♦ V 












♦ NO ♦♦♦♦ 










1 **♦♦ ♦ 


♦ 










♦ ♦ ♦ Cl 


* 












l~>^ HI ♦ ♦ 


* 







*****A^********** 

* * 
♦MOVE ARGUMENTS ♦ 

>* TO ♦- 

* BACK TARGET + 

* ♦ 
***************** 



**** 

* i 
->* El ♦ 

* 4 
♦ ♦♦* 



♦ ♦♦♦ 

* ♦ 

* Cl ♦ 

* ♦ 
***♦ 
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• chart 13. Strength Reduction (REDUCE- lEKQSR) 



REDUCE- lEKQSH 



****ht********* 
» PROM * 
* LPSEL-IEKPLS * 
► CHART 10 * 

^^t ************* 



DOES 

BACK 

TARGET 

♦.EXIST. 



mh 



****fi3********* 



*******i******* 



SEE TABLE 11 
*****(;l********** 

* TiPLOC-IEKQTX, ♦ 
*-»-i *-♦-♦- *-«-♦-» 

* INVESTIGATE *<— 
» PRIMARY * 

* CRITERIA * 
***************** 



PRIMARY *. NO 
CRITERIA .♦— 
MET . » 



YES .♦ ANY MOLT •• 
.M.».T£XT ENTRIES 



**** 

* * 

->* c3 ♦ 

* * 
**** 



. * ANY * . 
.NO .* ADDITIVE * 

. * ., >*.TEXT ENTRIES 

*. (+,-) .* 



TABLE 11 . 
♦****D3 *♦*♦♦***** 

* TYPLOC-IEKQTL ♦ 

* INVESTIGATE * 

* PRIMARY * 

* CRITERIA ♦ 

***************** 



LEGEND — 



El 



». 



conII^s 

. ENTRIES . 
*. ABS .* 
*. .* 
♦ NO 



7200 

*****Fl********** 

* GENERATE NEW * 

* TEXT ENTRY * 

* AND PLACE ♦- 

* IN BACK * 

* TARGET * 
***************** 



*****S2********** 

■'>*NfiW TADDITIVE) * 
• CONSTANT ♦ 



. *IS MOLT*. 

OR ADD 

CONSTANT 

ABS 



^. YES ♦ CALCOLATE « 

.♦ >* NEW (BRANCH) » 

" ♦ CONSTANT * 

* * 

****************4 



6200 

*****D<t ********** 

♦ GENERATE 2ND * 

♦ TEXT ENT FOR * 
*NEW BR CON AND * 

* PLACE IN BACK * 

* TARGET * 
***************** 



***************** 



SEE TABLE 13. 



NOTE : 
OPERAND 1 
BECOMES 
NEW ^ 
(ADDltlVE) 

constaiSt 



* GENERATE * 
->*NEW INERT TEXT *<- 

* ENTRY * 

* * 
***************** 



. ♦ IS BR ♦. 

VAR = 

ORIGINAL 

.INERT VAR. 



*'**Eit********** 



*WITH NEW BR CON* 
* * 

***************** 



9650 

*****FU ********** 

* DELETE * 

* ORIGINAL * 

* INERT * 

* TEXT * 

* ENTRY * 
***************** 



H2 ♦. 
.» IS ♦ 

. ♦ BRANCH 
. VARIABLE 
♦.BUSY-ON- 
*.EXlT .* 

*« .* 
* NO 



*****J2**** ****** 

* * 

* REPLACE * 
*0RIG1NAL BR VAR* 
*WITH NEW INERT * 

* VAR * 
***************** 



9900 

*****QH********** 

*REPLACE OPND 1 * 

* OF MULT. OR * 
— >* ADD TEXT * 

*ENTRY WITH NEW * 

* INERT VAR * 
***************** 



*****H1|********** 

* MOVE * 
*MOLTIPLICATIVE * 

* TEXT ENTRY TO * 

* BACK TARGET * 

* * 
***************** 



(ALL OTHER USES 
OF OPND 1, WHICH 
REMAIN IN THE 
LOOP, WILL ALSO 
BE REPLACED. ) 



.♦ WAS *. **** 

.* NON-INERT *. MOLT * 

.ENTRY MOLT OR.* >* C2 

*. ADD .* * 



. * WAS * 
. ♦ BRANCH 
. VARIABLE 
♦ . REPLACED 
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• Chart 14. Full Register Assignment (REGAS-IEKRRG) 



REGAS-IEKSKG 

****A2*+******* 

* FROM 1 

* LPSEL-IEKPLS ■< 

* CHfiRT 10 < 



* * 

* SUILD * 

* EMIN ARRAY * 

* FOR LOOP * 

* ♦ 



* CALL *. NC 
OR FUNCTION .* — 
». IN LOOP .♦ 



*****C2********** 

* * 

* DETERMINE * 

* RESERVED * 

* REGISTERS * 

* * 
♦****♦+*♦♦**♦***♦ 



* MAKE COMMON 

* VARIABLES IN- 

* ELIGIBLE FOR 

* GLOBAL 

* ASSIGNMENT 
**************** 



*****Y^2 *********"* 

* 4 

* SET POINTERS * 

* TO START OF * 

* FIRST BLOCK 1 

* 1 
***************** 
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*****D 3* **♦♦***** 

♦ GLOBAS-IEKRGB * 
*-*-*-♦-*-♦-*-♦-* 

♦ PERFORM ♦ 

* GLOBAL * 

* ASSIGNMENT ♦ 
***************** 



*****E3++*****+** 

* * 

* SET POINTER * 

* TO START OF * 

* FIRST BLOCK * 

* * 
***************** 



15A1 

*****F2********** 

* FWDPAS-IEKRFP ♦ 
*-*-*-*-*-*-*-*-♦ 
♦BUILD REGISTER ♦- 

* ASSIGNMENT * 

* TABLES * 
***+*»**++***♦♦♦♦ 



V 18B2 
*****F3 ♦♦♦***♦*** 

* STXTR-IEKRSX * 
*-♦-*-*-♦-♦-*-*-♦ 

* PERFORM *< 

* TEXT UP- ♦ 

* DATING * 
***************** 



* PERFORM * 

* LOCAL * 

* ASSIGNMENT i 
***************** 



*****GH ********** 

* * 

* SET POINTER * 

* TO START OF ♦ 

* NEXT BLOCK * 

* 4 

***************** 



V 
. + . 

H3 * 
* 

END 

OF 

LOOP 



****J3********* 

* TO * 

* LPSEL-IEKPLS * 

* CHART 10 ♦ 
*************** 
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chart 15. Table Building (FWDPAS-IEKRFP) 



FWDPAS'-IEKRFP 

♦♦♦♦Al ♦*♦♦♦*♦** 

* FROM * 

* REGAS-IEKRRG * 

* CHART 11 ♦ 
♦♦♦♦♦♦*♦**♦♦+♦* 



**^*i^f^2**** ****** 

* * 

* * 
>* INITIALIZE +- 

* * 

* * 
,^**^l**t********** 



4< 4< * « * A 3 * * '•"•"K'*"*"!'* * 

* * 

* INITIALIZE * 
->*FOR PROCESSING *. 

* TEXT BLOCK * 

* * 
♦♦♦**»*♦♦♦♦♦*♦*♦♦ 



Dl *, ♦**+*B2********** 

.* IS *. * ♦ 

.♦DLOCK BACK *. YES * * 

*TARG. OF INNER.* >* UPDATE RUSE *- 

♦. LOOP .* ♦ TABLE * 

*. . * * + 

*. .+ ♦♦♦♦♦♦»**♦♦*♦*♦** 



*****B3* ********* 





C2 *. 




. ♦ CAN * . 


* YES 


♦NEXT ELK OF* 


*< * 


LOOP BE PUT 


* 


*.IN TABLES.* 



4ii|i*N<************* 



♦♦♦♦*C3********** 

♦ FWDPSl-IEKRFl ♦ 
*-*-*-♦-+-*-*-*-♦ 

-* BUILD LOCAL *< 
*ASSGNMT TABLES * 

* FOR THE BLOCK * 



.* *, 

, *PROCESSING 
->*. COMPLETE 



|i****B4 ********** 



***************** 



*****C1|********** 
+ * 

* GET FIRST * 
-* (NEXT) TEXT * 

♦ENTRY IN BLOCK * 

* ♦ 
***************** 
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***** EH* ********* 

* BKPAS-IEKRBP ♦ 

* PERFORM * 

* LOCAL ♦ 

* ASSIGNMENT * 
♦*♦♦♦♦♦♦♦**♦++♦♦♦ 



F4 *. 
. * ♦. 
, ♦ END ♦• YES 

OF . * 

* . LOOP 



****A5********* 
^ TO * 

f REGAS-IEKRRG t 
► CHART It * 

*************** 



. * 
♦. . * 
* NO 

I 

♦ *** 

* ♦ 

* A2 * 

* ♦ 
**** 
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chart 16. Local Assignment (BKPAS-IEKRBP) 



JKl'AS-IEKRCP 



^***A1.******* + * 

FWDPA.g-IEKPFP * 
ClIAKT 15 1 
[( + + + + + + + + + + + *♦♦ 



* GET * 
->* BLOCK TO BE *- 

* PROCESSED * 



* PREVENT + 

* LOCAL * 
->*ASSIGNMENT FOR * 

+ EXTERNAL * 

* VARIABLES * 



** + + *p, ! + * + *♦ + * + ♦ + 
+ * 

* GET FIRST * 

* I NliXTl TEXT +< 
♦ENTRY IN BLOCK + 

+++♦♦+♦+*+++++++* 



♦=**C1. ******♦ + ** 

+ 

INITIALIZE * 

?0P TEXT *- 

FlnITRiT * 

* 



YFS 

+ *** 

->* C3 



* RET OPl OF * 

* SUP.SCR. ITEM 
+ h.m CURREFilT 

* OPERAND TO + 

* ZERO * 



+ <- 



D2 *. 




*****D3****** 


.♦ IS +. 




+ 


RECORD 


. + OPERAND A * . 


JO 


* 


DEFINITION 


>*. TEMPORARY .* 




>* 


POINT OF 


*. . ♦ 




* 


TEMPORARY 


+ . . + 




* 




*. . * 




** 


+***+++*+++ 


* YES 










1 ***♦ 










* * 










L->* C3 ♦ 










* * 











.+ UEFIWI- *. NO 

t.TIOi-J POINT IN.+ 

* . BLOCK . + 



*FLAG DEFINITION* 
♦POINT FOR TEMP.* 

* USED *- 

♦ in BLOCK * 



37 V 
+ *H< + *F3********** 

* PREVENT * 

* LOCAL + 
-> ♦ASSIGNMENT FOR ♦ 

♦ TEMPORARY + 

♦ ♦ 
+++++++♦+*+*♦♦+♦♦ 

♦ + + + 

♦ ♦ 
->♦ C3 * 

♦ * 
+ ♦ + ♦ 



(<*♦ + * + **** + ♦* 



. ♦ ALL ♦ . 

.TEXT ENTRIES . 

♦. PROCESSED. ♦ 



♦♦♦♦C5++******* 

♦ TO * 

♦ FWDPAS-IEKRFP ♦ 

♦ CHART 15 * 



+ ♦ 

♦ ACCOUNT + 
>* FOR SPECIAL * 

♦ CASES ♦ 

♦ ♦ 
♦♦♦♦++*♦♦+♦♦*+♦*+ 



V 
**+*+E5*++*++^+*+ 

♦ UPDATE TEXT ♦ 

♦ ENTRY WITH + 

♦ REGISTER AND *- 

♦ STATUS ♦ 
+ INFORMATION * 

:4c*4^%4:4:4< + ***** + * + + 



♦♦♦♦♦G5++******* 

♦ lEKRPl 
*-*-*-+-*-♦-♦-+- 

->* ASSIGN 

♦ REGISTER TO 

♦ OPERAND 
♦*♦♦♦*+***♦♦*♦+♦ 



** + * 
♦ 
->♦ C3 



¥****iri2***** 



.♦ PREVIOUS ♦. YES 
► . ASSIGNMENT IN.^ 
♦. EFFECT .♦ 



. + FLOATING 
^. POINT 

* . MADE 





♦ ASSIGNMFHT ♦ 
**♦»*+*♦**♦♦*♦♦♦♦ 




+ + 

L_>^ c:! ♦ 

♦ ♦ 




♦ ♦♦♦ 


NO 





.♦ OPl ♦. 
. ♦ ASSIGNED * 
->*. FIXED-POINT 
♦.REGISTER .♦ 



} V 

♦♦♦♦♦j3+*++++++++ 

♦ SEARCH ♦ 

♦ FOR AVAILABLE ♦ 

♦ REG. FREE ONE ♦- 
+ IF NECESSARY ♦ 

♦ ♦ 
++♦+♦+♦♦*++♦+♦♦♦+ 



♦ TRY TO ASSIGN ♦ 

♦ TO CURRENT + 
-> + OPRND THE SAI>1E ♦- 

+ REG. AS ♦ 

♦ OPERAND 1 ♦ 
♦♦♦♦♦♦+♦♦♦♦♦♦♦♦♦♦ 



♦ ♦♦♦+JI|*^* + + + ^ + + ^ 

♦ RECORD * 
->* ASSIGNMENT ♦- 

♦ INFOPM/iTION ♦ 

♦ ♦ 
*♦♦♦+♦*♦♦+++♦♦♦♦♦ 



♦♦♦♦♦H5+**+****++ 

♦ * 

♦ RECORD ♦ 
->♦ ASSIGNMENT ♦ 

♦ INFORMATION * 

♦ ♦ 



♦ + ♦♦ 

♦ C3 ♦ 

♦ ♦ 
♦♦++ ♦♦++ 

* ♦ 
>♦ C3 + 



++*++K !+♦♦♦♦♦♦+♦♦ 

♦ SEARCH ♦ 

♦ iXiA AVAILABLE + 

♦ REG. FREE ONE ♦<- 

♦ IF NECESSARY + 



. ♦ OFERAllD 1 ♦. YEE: 

, ASSIGNED A . ♦ 

♦. REG. .♦ 



♦ ♦♦< 



^♦♦♦♦♦♦♦♦♦♦♦< 



♦♦♦♦♦K3*^++*+^^++ 
+ TRY TO * 

♦ ASSIGN TO ♦ 
>♦ CURRENT OPRND ♦- 

♦ THE SAME REG. * 

♦ AS OPERAND 1 ♦ 
♦♦+♦♦++♦♦♦♦♦*♦+♦* 



♦ 

♦ RECORD 
>♦ ASSIGNMENT 

♦ INFORM/VTION 

♦♦♦♦♦*♦♦♦*♦♦♦*♦ 
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Chart 17. Global Assignment (GLOBAS-IEKRGB) 



GL0BAS-IEKKG3 



****A1********* 
FROM 1 
REGRS-IEKRRG » 
CHART m * 

f * * * H< * * * :<< * 4i * * * * 



♦***»A2 **♦*♦***♦♦ 

♦ ♦ 

* * 
->* INITIALIZE ♦- 

t * 

♦♦*♦+**»♦♦♦♦♦**♦* 



* COMPUTE 1 
>* REGISTER * 

* AVAILABILITY < 

* i 



♦****A4********** 
♦COMPUTE NUMBER * 

* OF OPERANDS * 
>* THAT ARE *- 

♦CANDIDATES FOR ♦ 

* ASSIGNMENT ♦ 



:^Df***f^^* ******** if 

* + 

* CALCULATE * 
->* BASE REGISTER * 

* ACTIVITY ♦ 

* * 
***************** 



V 

♦PREVENT GLOBAL* 

♦ ASSIGNMENT TO ♦ 

♦ BUSY-ON-EXIT, ♦- 

♦ STORED ♦ 

♦ VARIABLKS ♦ 
***************** 



♦♦♦♦♦El ♦♦♦*♦♦♦♦♦♦ 

♦ ♦ 

♦ UPDATE TEXT ♦ 

♦ TO REFLECT :♦ 

♦ ASSIGNMENT ♦ 

♦ ♦ 

♦ ♦♦*♦♦♦♦♦♦♦♦♦♦♦♦:♦ 



♦♦♦♦♦Gl *♦♦*♦*♦♦♦+ 

♦ + 

♦ ASSIGN REGISTEpt*<- 

♦ ♦ 

♦ ♦ 
♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 



ril ♦. 
.* REG. *. 
, ♦ ASSIGNED 
♦. TO ITEM IN 
♦ . INlKi^ . 
♦.LOOP .♦ 
♦. . ♦ 
♦ YES 



. ♦ THIS AN 
->♦. OUTERMOST 
♦ . LOOP 



10 .♦. 

C2 ♦. 
. ♦ ANY ♦ . 
.♦FLOATING PT*. NO 

♦ RE'.GS AND ELIGI- + -- 

♦.BLE VARS .♦ 

♦ . . ♦ 

* . . ♦ 



♦ SEARCH FOR ♦ 
♦CANDIDATE WITH ♦ 

♦ HIC3HEST ♦ 

♦ ACTIVITY ♦ 
***************** 



, ♦ VA!^IASLE ♦. NO 

OR CONSTANT .♦ 

♦ • FOUi-ID .♦ 



♦♦♦♦♦P2^*^*^^*^*^ 

♦ * 

♦ SEARCH FOR ♦ 

♦ AVAILABLE ♦ 

♦ REGISTER ♦ 

♦ ♦ 
♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 



25 
*****B3********** 

♦ DOWNGRADE ALL ♦ 
♦VARIABLES THAT ♦ 

-■>♦ ARE STORED IN ♦ 
♦THIS OUTERMOST ♦ 

♦ LOOP ♦ 
«♦♦♦*♦♦♦♦♦♦♦♦♦♦♦« 



V 

. ♦. 

C3 ♦. 

. ♦ ANY +. 

FIXED PTS 

REGS AND 

.ELIGIBLE • 

+.VARS .♦ 

♦. . ♦ 

♦ YES 



V 
♦♦♦♦♦D3^+*^*^^^+^ 

♦ SEARCH-IEKRS ♦ 

♦ GET CANDIDATE ♦ 

♦ FOR BXH OR ♦ 

♦ BXLE INST. ♦ 
♦♦♦♦«♦♦♦♦«♦♦♦♦*♦♦ 

♦ ♦** 

♦ ♦ 

♦ E3 *-> 

♦ ♦ 

♦ ♦♦♦ 
LI 

♦♦♦♦♦E3*f^^*^^+** 

♦ ♦ 

♦ SEARCH FOR ♦ 
♦CANDIDATE WITH * 

♦ HIGHEST ♦ 

♦ ACTIVITY ♦ 
♦♦♦♦*♦♦♦♦♦♦♦♦♦♦♦♦ 



G3 ♦. 

♦ 

FOUl-ID 



.♦ ITEM ♦. YES 

->♦. INCREMENT FOR.* — — 
♦.BXLE, BXH .♦ 



35 
*****yi^* ********* 

♦ TRY TO ♦ 

♦ ASSIGN THE 3 ♦ 
->^REGS NECESSARY ♦ ' 

♦FOR BXLE OR BXH^ 

♦ ♦ 
♦♦♦♦*♦♦♦♦♦♦♦♦♦♦♦♦ 



****CH********* 
!• TO " 
► REGAS-IEKRRG < 
* CHART It « 

•♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 



*****QH*i******** 

♦ * 
♦IF BXH OR BXLE, * 

>♦ DO FINAL ♦< 

♦ PROCESSING ♦ 

♦ ♦ 
***************** 



ASSIGNMENT . 

♦.SUCCESS- .♦ 

♦ . FUL . ♦ 



*****JH********** 

♦ * 
♦ASSIGN VARIABLE* 
♦OR CONSTANT TO ♦ 

♦ REGISTER ♦ 

♦ ♦ 
***************** 



*****KH*** ******* 

♦ UPDATE TEXT * 

♦ TO REFLECT ♦- 

♦ ASSIGNMENT ♦ 

♦ ♦ 
♦♦♦♦♦♦♦♦♦♦♦♦*♦♦«♦ 
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Chart 18. Text Updating (STXTR-IEKRSX) 



>i****ii**M****** 



« % ^ * « it( )4i 4( 

* STORE ♦ 

* RESULTS INTO * 

* TEXT * 
+ * 
+***♦*♦******+♦♦♦ 



* * 

* SAVE INFO. ♦ 

* RELATING TO + 
♦NEXT TEXT ENTRY* 

* ♦ 



STXTR-IEKRSX 

♦♦♦*A2********* 

* FROM 1 

* REGAS-IHKRRG * 

* CHART It ■< 



*****'a2** ******** 

* * 

* INITIALIZE ♦ 
♦GET FIRST TEXT ♦ 

* ENTRY ♦ 

* * 

*t*****t^!^*^#***^ 



.END OF BLOCK 



♦♦♦♦C3^^+*+^^+^ 

♦ TO * 
->* REGAS-IEKRRG < 

♦ CHART in ^ 
*************** 



*****n2* ********* 

* GET ANY ♦ 

* CC^PLETED ♦ 
♦ASSIGNMENTS FOR* 

* TEXT ENTRY ♦ 

* * 
***************** 



*****S2* ********* 

♦ * 
♦INITIALIZE FOR ♦ 

♦ PROCESSING ♦ 

♦ ACCORDING TO ♦ 

♦ OPERATO« ♦ 
***************** 



**** 

♦ 18 * 

♦ F2 ♦-> 

♦ ♦ 

♦ ♦♦♦ 

130 F2' 



***+*P3+^+*+**+** 



;:i 



♦ OPRND 2 1 

TO BE PROC- 
*. ESSSD .1 



♦ OPRND 3 

TO 3E PROC- 
♦. E3SED 



***************** 



*****G3* ********* 



***************** 



******** 

* * 

* UPDATE TEXT ♦ 
♦TO SHOW GLOBAL ♦ 

* ASSIGNMENT ♦ 

* * 
***************** 



220 


G« ♦. 




.♦IS ♦ 


. * 


OPERAND A 


>*. 


TEMPORARY 



♦♦♦♦♦HI ♦♦♦♦♦♦♦♦♦♦ 

♦ PERFORM FINAL ♦ 
♦PROCESSING FOR ♦ 

♦ SPECIAL ♦< 

♦ CASES ♦ 

♦ ♦ 
***************** 



* OPRND 1 ♦. YES 

TO BE PROC- .♦ 

♦. ESSED .♦ 



►♦♦♦♦H3^+^****^^^ 



***************** 



***** 

♦ 19 ♦ 

♦ B3^ 
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Chart 19, Text Updating (STXTR-IEKRSX) (Continued) 



*19 * 
♦ B3* 



CI *. 
. * WAS + . 

OPRND 2 * 
ASSIGNED BY 
. BKPAS . * 
*. . ♦ 


YES 


*. . * 


V 




► NO 


***** 

♦ 18 * 

* F2* 



♦ OPRND = 

OPUND 1 OF 

♦.PREVIOUS . 

♦.ENTRY. ♦ 



YES 



*♦** 

* ♦ 

* Fl ♦-> 

* * 
♦ *** 

325 Fl" 



*****02^ ♦♦♦♦♦♦♦*♦ 

♦ USE ♦ 

♦ SAME REG. AS ♦ 
, ♦ > + OPl OF PREVIOUS* 

♦ TEXT ENTRY ♦ 

♦ ♦ 
***************** 



E2 

* 

REG. 



***** 

♦ 18 ♦ 

♦ F2* 



IS *. 
f BASE ♦ 
REGISTER OK 



Gl ♦. 
♦ IS ♦• 
OPRND * 
TEMPORARY 



***** 

♦ 18 * 

♦ F2^ 



YES 



*****Q2^**^^**^*^ 

♦ RECOR-IEKRRL ♦ 

, ♦--- >♦ FREE STORAGE ♦ 

♦ FOR TEMPORARY ♦ 

♦ IF POSSIBLE ♦ 
***************** 



.♦ WHICH ♦. 
, ♦OPRND BEING*. 
, PROCESSED . ' 



C3 ♦. 

. * WAS ♦ . 
» OPRND 1 ♦ 

ASSIGNED BY 
* . BKPAS . ♦ 



.♦ MUST ♦. 
, ♦OPRND 1 SE 
STORED 



♦ ♦**♦ 

♦ 18 ♦ 

♦ F2 + 



♦ SET STATUS * 

♦ TO GENERATE * 

♦ STORE * 

♦ 4 
***************** 



EM ♦. 

. ♦ MUST ♦. 

OPRND 1 

BE STORED 



330 .♦. 


C5 ♦. 


. + WAS ♦ . 


YES .♦ OPHND 3 *. 


r— ♦. ASSIGNED BY .* 


♦ . BKPAS . ♦ 


♦. . ♦ 


V ♦. . * 


♦ ♦ ♦ * ♦ ♦NO 


♦ 18 ♦ 




♦ F2^ 




* * 




* 




V 


. *. 


D5 ♦. 


.♦IS ♦. 


NO .♦ OPRND = *. 


r — *, OPRND 1 OF .♦ 


♦ .PREVIOUS .♦ 


♦. ENTRY. ♦ 


V *. .♦ 


♦♦♦♦ * YES 


♦ ♦ 




♦ Fl ♦ 




♦ ♦ 




♦ ♦♦♦ 




<^ 


*****-E5* ********* 


* USE ♦ 


♦ SAME REG. AS ♦ 


♦OPl OF PREVIOUS^ 


♦ TEXT ENTRY * 


* ♦ 


+♦♦♦♦♦♦♦♦♦♦♦***** 



, * 

'♦'yes 



*****G3******+*** 

♦ ♦ 

♦ ALLOCATE ♦ 

♦ STORAGE FOR ♦ 

♦ TEMPORARY ♦ 

♦ ♦ 
***************** 



♦ SET STATUS < 

♦ TO PREVENT i 

♦ STORE * 

♦ 4 
****************4 



*♦♦** 

♦ 18 ♦ 

♦ F2* 
♦ * 



90330 


. ♦. 




F5 ♦. 




♦ ♦ 


NO .♦ 




1 * , 


REG. 


* 






♦. . ♦ 


" 


♦ . . ♦ 


**** 


♦ YES 


♦ * 




♦ Fl ♦ 


I 


* ♦ 


^ 


**** 


***** 




♦ 18 ♦ 




♦ F2^ 




♦ * 



k***H3********** 

FIND BASE ♦ 

REG. FOR ♦ 

OPERAND ♦ 

♦ 

K*************** 



V 

*****J3********** 

♦ RECORD ♦ 

♦ BASE INFO. ♦ 

♦ FOR ♦ 

♦ APPROPRIATE ♦ 

♦ OPERAND * 
***************** 
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• Table 11, Criteria for Text Optimization 

I Basic I 



Process 



Primary 



Secondary 



h 



Common | Subscript, arithmetic, j Matching operand 2, jMatching operand 2, 
Expression j logical, or j operand 3, and joperand 3, and 
Elimination ] binary operator | operator | operator with 
I I I no intervening 
I I I redefinitions 
+ „ 4- +- 

Backward | Arithmetic or logical | Operand 2 and ] Operand 1 not busy 
Movement | operator joperand 3 undefined jon exit from target; 
I Jin the loop (operand 1 undefined 
I 1 ] elsewhere in the loop 
1 f + _ 

strength [Additive operator; ] Interaction of inert j Function of absolute 

Reduction j inert variable } variable with additive J constants or stored 

I I or multiplicative j constants 

I operator j 
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• Table 12. Phase 20 Subroutine Directory (Part 1 of 2) 

r T 

I Subroutine 1 Function 



Type 



h 



BACMOV-IEKQBM 



BAKT-IEKPB 



BIZX-IEKPZ 



BKDMP-IEKRBK 



BKPAS-IEKRBP 



BLS-IEKSBS 



CXIMAG-IEKRCI 



FCLT50-IEKRFL 
(TNSFM-IEKRTF)* 
(RELCOR-IEKRRL) ♦ 



FREE-IEKRFR 

FWDPAS-IEKRFP 

FWDPSl-IEKRFl 

IGLOBAS-IEKRGB 
lEKPBL 

ILOC-IEKRLl 
LPSEL-IEKPLS 
REDUCE- lEKQSR 



Controls backward movement, produces new inert text 
entries for strength reduction, builds type tables for 
strength reduction, and performs compile-time mode 
conversions. 

Computes the loop number of each module block. 



Computes the proper MVX setting for each variable in 
each block of the module. 

Produces TRACE for full register assignment. 



Controls local register assignment. 



Computes the total size of each block in the module and 
determines which module blocks can be reached via RX- 
forraat branch instructions. 

Processes imaginary parts of complex functions during 
local register assignment. 

Performs special checks on text items whose function 
codes are less than 50, 



Secondary entry point TNSFM-IEKRTF performs special 
checks on text items whose function codes are in the 
range of 50 to 55 inclusive. 

Secondary entry point RELCOR-IEKRRL releases temporary 
main storage so it can be reused. 

Releases busy registers during overflow conditions 
(local assignment). 

Table-building routine for full register assignment. 



Determines whether or not text operands are register 
candidates prior to local register assignment. 

Assigns most active variables to registers across the 
loop. 

COMMON data area for structural determination. 



BLOCK DATA subroutine for register assignment. 



Controls sequencing of loops and passes control to text 
optimization and register assignment routines 

Controls strength reduction. 



Text 
optimization 



Structural 
determination 

Structural 
determination 

Register 
assignment 

Register 
assignment 

Branching 
optimization 



Register 
assignment 

Register 
assignment 



Register 
assignment 



Register 
assignment 

Register 
assignment 

Register 
assignment 

Register 
assignment 

Register 
assignment 

Structural 
determination 

Register 
assignment 

Control 
routine 

Text 
optimization 



j ♦Secondary entry point 

L 



Section 2: Discussion of Major Components 107 



• Table 12. Phase 20 Subroutine Directory (Part 2 of 2) 



I Subroutine 



Function 



I Type 



^ 4. + 4 



REGAS-IEKRRG 



SEARCH- lEKRS 



SPLRA-IEKRSL 



SSTAT-IEKRSS 



STXTR-IEKRSX 



TALL-IEKRLL 



TARGET- lEKPT 



TOPO-IEKPO 



Controls full register assignment. 



Register 
assignment 

Register 
assignment 

Register 
assignment 

Register 
optimization 

[Register 
assignment 

I Register 
assignment 

Text 
optimization 

Structural 
determination 

Text 

optimization 
^ J. „„ X 4 

I * Secondary entry point j 

L -. . . J 



Provides register loads upon entering the module. 



Assigns registers during basic register assignment. 



Sets status information for operands and base addresses 
of text entries. 

Controls text updating. 



Assigns storage for temporaries. 



Identifies the members of a loop and its back target. 



Computes the immediate back dominator of each block in 
the module. 



XPELIM-IEKQXM ] Controls common expression elimination. 
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• Table 13. Phase 20 Utility Subroutines 



j Subroutine 



Function 



CIRCLE-IEKQCL 
( FOLLOW- lEKQF)* 

CLASIF-IEKQCF 

(PARFIX-IEKQPX)* 

(MODFIX-IEKQMF)* 

GETDIK-IEKPGK 
(FILTEX-IEKPFT)* 
(GETDIC-IEKPGO* 
( INVERT- lEKPIV)* 
( -lEKPOV)* 

lEKARW 

lEKPOP 

KORAN- lEKQKO 
(LORAN-IEKQLO)* 

MOVTEX-IEKQMT 
(DELTEX-IEKQDT)* 

PERFOR-IEKQPF 

SRPRIZ-IEKQAA 
( -lEKQAB) * 

SUBSUM-IEKQSM 



TYPLOC-IEKQTL 
WRITEX-IEKQWT 



XSCAN-IEKQXS 

(YSCAN-IEKQYS)* 

(ZSCAN-IEKQZS)* 



i Examines composite vectors, or each local vector if necessary. 

I Classifies operands of the current text entry, changes parameter list 
I to correspond to text replacements, and adjusts text entry for 
[possible mode change. 

Fills text space according to the arguments, gets space for tem- 
poraries, gets space for constants, and obtains previous text entry. 



Calls FIOCS# to rewind the required data set. 

Common data area for phase 20. 

Performs bit manipulation for text optimization, updates composite 
LMVS and LMVF matrixes. 

I Moves text entries, deletes current text entry by rechaining, and 
updates MVS and MVF vectors. 

Performs combination of constants at compile time. 

Records structured source program listing on the SYSPRINT data set. 

I Replaces operands with equivalent values and, if possible, operand 
lvalues with equivalent values. 

[Locates interaction of text entries for strength reduction. 

Prints diagnostic trace information when text optimization and TRACE 
option are specified. 

Performs local block scan for backward movement, for common expression! 
elimination, and for strength reduction. 



I *Secondary entry point 

L 



Section 2: Discussion of Major Components 109 



chart 20. Phase 25 Processing 



^■';<0^ FSD 
CriHKT 01 



ANY 
'E* BLOCK 
LABELS . 



*****fi J*** ******* 

* * 

* ASSIGN EASE * 
>♦ AND DISP. * 

* TO ' B' BLOCK * 

* LABEL ADCONS ♦ 
^,t*************** 



S03ROUTIN£ 
MAINGN-IEKTA 
CONTROLS TEXT 
CCNVESSION 



TO Ft)D * 
ClART 01 * 



ANY 
BKANCH 
TABLES 



* * 

* GET FIRST * 

* (NEXT) TLXT ♦ 

* ENTRY * 

* * 

*^^4:***i^**^******* 



.♦RETURN ♦. 

. * I/O, END, *. 

STMT. 



+*++♦£ 2********** 

* + 

* SET UP * 

* REGISTER * 
+ ARRAY * 
+ * 

tif***t:t********** 



t**F2********** 

* 

SELECT * 

BIT * 

STRIP * 

*************** 



t*t**G2 ********** 

* * 

* MODIFY STRIP * 

* FOR BASE * 

* LOADS AND * 

* STORES * 



*t***B3*** ******* 

* * 

* ASSIGN EASE * 
>* AND DISP. * 

* TO BRANCH * 

* TABLES * 
**t************** 



-*_♦_*_*-*_*_* 



>* DETM ENT TYPE *<- 
♦PRODUCE LBL MAP* 
♦IF END OF TEXT * 

:tiH,***t**t******* 



Bl 1 

4 

»♦♦♦ 



*****Q^* ********* 

♦ RETURN-IEKTRN * 
«_*,♦_♦_♦-♦-*-♦_♦ 

>* GENERATE * 

♦ BRANCH TO ♦ 

♦ EPILOGUE ♦ 

^tt*4t.**iH^*tlt**** 



*****C5* ********* 

♦ lOSUB^IEKTIS ♦ 
*_♦-♦-«-♦-*-*-*-* 

->*GENERATE BRANCH* 

♦ TO IHCFCOKH ♦ 

♦ ♦ 
ti,ttin*^nn,**^,**** 



♦ LABEL- lEKTLB * 
*_♦-♦.,*,♦_♦,*-♦-♦ 

>* ENTER LOG. ♦ 

♦ CTR. IN * 

♦ LABEL ENTRY ♦ 
*^i**** *********** 



21fi2 

*****1^^* ********* 

* END-IEKUEN * 
*_*_♦_ + _*_♦-♦-.♦-* 

>* COMPLETE * 

* PROCESSING * 

* OF MODULE ♦ 
***************** 



*****p^********** 

♦lEKGMP ♦ 

*„*-*^*-,*^*-*.^*^* 
<„_,>♦ PRODUCE * 

♦ STORAGE ♦ 

* MAP ♦ 
***************** 



I/O 
LIST 
ITEM 



*****^2*** ******* 

* * 4 
*-*-*-*-*-*-*-*- i 

* GENERATE * 

♦ INSTRUCTIONS ■• 

♦ FROM SKELETON i 
**t***t*********^ 



■>♦ Bl < 

♦ i 
**** 



*****llj* ********* 

* FNCALL-IEKVFN ♦ 
♦-♦-♦-♦-*-♦-♦-+-♦ 

>* GENERATE ♦ 

* CALLING ♦ 

* SEQUENCE ♦ 
******S********** 

**** 
* * 

->* Bl ♦ 
+ ♦ 

**♦♦ 

*****j2********** 

* SUBGEN-IEVSU ♦ 
♦-♦-♦-«-♦-♦-♦-*-♦ 

>♦ GENERATE * 
+ TEXT FOR ♦ 

* LIST ITEM * 
***************** 

**** 
t ♦ 
► Bl * 
» ♦ 

♦ ♦*♦ 
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• Chart 21. Subroutine END-IEKUEN 



****hi******** 

* Fko^; 

* k«INGN-IEKTR 
!■ CHAKT 20 



->+DETPH^'I^IE TYPl. *<- 
* OF PROLOGU£ * 
*LPILCGOE TO GEN* 



W 
*****B2********** 

* OUTPUT ACCONS * 

* FOR PROLOGUE, * 

* SAVE AREA, ♦ 

* EPILOGUE ♦ 

* ♦ 



Hf^tft-tni^^iHr* 



♦ PROLOG- lEKTPR ♦ 

-* GENERATE + 

♦ PROLOGUE ♦ 

♦ * 



ANY 
BRANCH 
TABLES 



* * 

* OUTPUT ADCONS * 
>♦ FOR BRANCH * 

* TABLES ♦ 

* * 
***************** 



ANY 
PARAMi";TER 
. LISTS . 



*****D3********** 

* OUTPUT ADCONS * 
->* FOR PARAMETER ♦ 

* LISTS * 

* ♦ 
***************** 



*.ANY P20 TEMP..*- 



*****^;^*** ******* 



***************** 



ANY 
■E' ELOCK 
LAEELS . 



*****(32********** 

* * 

* OUTPUT END + 

* CARD FOR ORJ. * 

* KODULE * 

* * 
***************** 



****}i2** ******* 
K TO t 
!■ MAINGN-IEKTA * 
► CHART 20 * 

*************** 



*****p J*** ******* 

* * 

* OUTPUT * 
->*ADCONS FOR 'B' * 

* BLOCK LABELS ♦ 

* ♦ 
***************** 
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• Table lU. Phase 25 Subroutine Directory (Part 1 of 2) 



j Subroutine 
I" 



Fuiiction 



ADMDGN-IEKVAD^ 



BITNFP-IEKVFP^ 



BRLGL-IEKVBL=>- 



CGEN- lEKWCN 



Generates instructions for the AMOD, DMOD, ABS, lABS, DABS, AND, OR, 
COMPL, LCOMPL, and DBLE in-line functions. 

Generates instructions for the following text entries: BITON, 
BITOFF, BITFLP, TBIT, MOD24, SHFTR, and SHFTL in-line functions. 

Generates instructions for the following text entries: Operator is 
a relational operator operating upon two operands or upon one 
operand and zero, assigned GO TO operators, computed GO TO opera- 
tors, unconditional branching, branch true and branch false opera- 
tions, and ASSIGN statement. 

Common data area in which the arrays used during code generation are 
initialized. 



END-IEKUEN 
ENTRY- lEKTEN 

EPILOG- lEKTEP 

FAZ25-IEKP25 
FNCALL-IEKVFN 

GOTOKK-IEKWKK 



Performs final processing of the object module. 

Calls routines PROLOG- lEKTPR and EPILOG-IEKTEP to generate prologues 
and epilogues for subroutines and secondary entry points. Generates 
prologues and epilogues for the main program. 

Generates the epilogues associated with 3 subprogram and its second- 
ary entry points (if any). 

Common data area used by phase 25. 

Generates calling sequences for CALL statements (other than those to 
IHCFCOMH) and function references. Generates the instructions to 
store the result returned by a function subprogram. 

Used by subroutine MAINGN-IEKTA to branch to the code generation 
subroutines. 



lOSUB-IEKTIS/ 
I0SUB2-IEKTI0 



Generates calling sequences for calls to IHCFCOMH. 



LABEL- lEKTLB 



LISTER- lEKTLS 

MAINGN-IEKTA/ 
MAINGN2-IEKVM2 

PACKER- lEKTPK 



PLSGEN-IEKVPLi- 



PROLOG-IEKTPR 



RETURN- lEKTRN 



STOPPR-IEKTSR 



Processes statement numbers by entering the current value of the 
location counter into the statement number entry in the dictionary. 

Produces a listing of the final compiler-generated instructions. 

Assign base and displacement for 'B* block label adcons and branch 
tables. Control the text conversion process of phase 25. 

Packs the various parts of each instruction produced during code 
generation into a TXT record. 

Generates the instructions for the following text entries: real 
multiplication and division operations, addition and subtraction 
operations, half- and full-word integer multiplication, half- and 
full-word integer division, and MOD in-line function. 

Generates prologues for subroutines and secondary entry points (if 
any) . 

Processes the RETURN statement by generating a branch to the 
epilogue. 

Generates character strings in calls to IHCFCOMH for STOP and PAUSE 
statements. 



I ^Code generation subroutines. 

L 



112 



• Table lU. Phase 25 Subroutine Directory (Part 2 of 2) 



j Subroutine 



Function 



SUBGEN-IEKVSU^ 



TENTXT-IEKVTN 



TSTSET-IEKVTS^ 



UNRGEN-IEKVUNi- 



Generates instructions for the following text entries: subscript 
operations, right and left shift operations, store operations, and 
list item operations. 

Controls the processing of END, RETURN, and input/output statements, 
statement n\ambers, and end of I/O list indicators. Produces label 
map. 

Generates the instructions to (1) compare two operands across a 
relational operator, and (2) set operand 1 to either true or false 
depending upon the outcome of the comparison. Generates the follow- 
ing in-line functions: FLOAT, DFLOAT, INT, IDINT, IFIX, HFIX, DIM, 
IDIM, SIGN, ISIGN, DSIGN, MAX2, and iyiIN2. 

Generates the instructions for the following text entries: unary 
minus operations (e.g., A=-B) , logical NOT operations, load byte 
operations, load address operations, AND, OR, and XOR operations. 



lEKGMP I Produces a storage map. 
J. ± „ 

I ^i-Code generation subroutines, 

L • . 



Table 15. Phase 30 Subroutine Directory 

r ■" T— • T 

I Subroutine I Function | 

|. + „ ^ 

j IEKP30 I Controls phase 30 processing. | 

I I I 

I MSGWRT- I Writes the error messages using the FSD. | 

I IEKP31 1 I 

L . ± . . J 
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Chart 22. Phase 30 (IEKP30) Overall Logic 



*♦** A3 ********* 

* FROM * 
" FSD * 

* CHART 01 * 



*****I33 + + + + ** + + + * 

* * 
+ + 

* INITIALIZE * 

* * 
+ * 



V 
++*+*C3********** 

* OBTAIN i'lAXIMUM ■* 

* ENTRIES AND * 
*ACTUAL ENTRIES * 

* FROM COMMON * 



SEE TABLE 15 

FOR A BRIEF 

DESCRIPTION OF 

EACH SUBROUTINE 

OF PHASE 30. 



.♦ACTUAL *. 


.*N0. GREATER*. 


*. THAN THAT . 


* . ALLOWED . * 


*. . * 


+ . . * 


* NO 


+ *** 




* * 




* E3 *-> 




+ * 




** + + 




jDERCOK V 


++***E3*******+* 
* OBTAIN FIRST 


* (NEXT) ERROR 


* TABLE 


ENTRY 



]f*^LiHL^f**>^t***if 



V 

. * . 

F3 *. 

.♦MESSAGE*. 

. + NUMBER * 

.L/T 1000 AND 

*. G/T .♦ 



****D1)********** 

SET UP ERROR * 

MESSAGE * 

AND *- 

LENGTH * 

+ 

♦♦♦+♦**♦+♦*♦+**+ 



STRESSl 

* SET UP 

* ADDRESS 
>♦ FOR ERROR 

* MESSAGE 



!>*♦♦ + * + + ♦ + :( 



V 
+*++*G3^+***+**** 

* OBTAI N * 

* ERROR LEVEL * 

* CODE FROM * 

* GRAVERR * 

* TABLE + 
*♦♦*♦+***♦♦+**+♦+ 



.* ERROR *. 
. +LEVEL CODE * 
.G/T PREVIOUS 
* . ONES . » 



V 

i'***J3*** + ****** 

GET + 

ASSOCIATED * 

MESSAGE * 

POINTER TABLE * 

EiJTRY * 

^♦♦♦♦♦♦♦♦♦+**+++ 



♦♦♦♦*K3********** 

* BUILD * 

* PARAMETER *- 

* LIST ♦ 



OFFSET 

♦ ♦♦♦♦F5*^** + ***'t 

♦ MSGWRT-IEKP31 



-+-♦-*-*- 



WRITE 
ERROR 
MESSAGE 
*♦++*+**♦♦* 



♦♦♦♦♦HI********** 

♦ SAVE ♦ 

♦ ERROR * 
>* LEVEL ♦ 

♦ CODE ♦ 



I'********* 



!.♦*♦* 





G5 


* . 




. * LAST ♦ . 


NO 


♦ ERROR * . 


. ♦ 


TABLE . ♦ 




*. ENTRY .♦ 




+ . . ♦ 


•J 


* . • * 


♦ ♦♦ + 


■* YES 


* 






E3 ♦ 






♦ 






♦ ♦♦♦ 






OUT 


V 


♦♦♦♦♦H5*+^ ***++** 


♦ 


PASS SAVED * 


+ 


ERROR + 


♦ 


LEVEL * 


♦ 


CODE * 


He 




t******* 


********* 



f**j5********* 

TO ■• 

FSD ^ 

CHART 01 * 

If************* 



**** 

* * 

* F5 * 



nil 



APPENDIX A: 



TABLES 



This appendix contains text and figures 
that describe and illustrate the major 
tables used and/or generated by the FORTRAN 
System Director and the compiler phases. 
The tables are discussed in the order in 
which they are generated or first used. In 
addition, table modifications resulting 
from the compilation process are explained, 
where appropriate, after the initial for- 
mats of the tables have been explained. 



COMMUNICATION TABLE (NPTR) 



The communication table (referred to as 
the NPTR table in the program listing) , as 
a portion of the FORTRAN System Director, 
resides in main storage throughout the com- 
pilation. It is a central gathering area 
used to communicate necessary information 
among the various phases of the compiler. 

Various fields in the communication 
table are examined by the phases of the 
compiler. The status of these fields 
determines : 

• Options specified by the source 
programmer. 

• Specific action to be taken by a phase. 

If the field in question is null, the 
option has not been specified or the action 
is not to be taken. If the field is not 
null, the option has been specified or the 
action is to be taken. Table 16 illus- 
trates the organization of the communica- 
tion table. 



CLASSIFICATION TABLES 



Classifying, a function of the prepara- 
tory subroutine (GETCD-IEKCGC) of phase 10, 
involves the assignment of a code to each 
type of source statement. This code indi- 
cates to the DSPTCH-IEKCDP subroutine which 
subroutine (either keyword or arithmetic) 
is to continue the processing of that 
source statement. The following paragraph 
describes the processing that occurs during 
classifying. The tables used in the class- 
ifying process are the keyword pointer 
table and the keyword table. They are 
illustrated in Tables 17 and 18, 
respectively. 



If the source statement has not been 
signaled as arithmetic during source state- 
ment packing (see note), the classifying 
process determines the type of the source 
statement by comparing the first character 
of the packed source statement with each 
character in the keyword pointer table. If 
that first character corresponds to the 
initial character of any keyword, the key- 
word pointer table is then used to obtain a 
pointer to a location in the keyword table. 
This location is the first entry in the 
keyword table for the group of keywords 
beginning with the matched character. All 
characters of the source statement, up to 
the first delimiter, are then compared with 
that group of keywords. If a match results, 
the classification code associated with the 
matched entry is assigned to the source 
statement. If a match does not result, or 
if the first character of the source state- 
ment does not correspond to the first 
character of any of the keywords, the 
source statement is classified as an inval- 
id statement. 



Note: The packing process, which precedes 
classifying, marks a source statement as 
arithmetic if, in that statement, an equal 
sign that is not bounded by parentheses is 
encountered. If the source statement has 
been marked as arithmetic, it is classified 
accordingly by the classification process. 



•Table 16. Communication Table [NPTR(2,35)] 
(Part 1 of 3) 



1—4 



I— + 



J— 4 



Pointer to tempo- 
rary for FLOAT/FIX 



Previous classifi- 
cation code (phase 
10) 



Options: DUMP, XL, 
XREF, ID, EDIT, 
MAP, LOAD, DECK, 
LIST, BCD, SOURCE 



■4 



Pointer to most 
recently generated 
EQUIVALENCE group 
entry (phase 10) ; 
Relative location 
of first temporary 
(phase 20) 



Pointer to 1- 
acter symbol 



char- 
chain 



Pointer to 2- 
acter symbol 



char- 
chain 



Pointer to 3-char- 
acter symbol chain 



Pointer to 4- 
acter symbol 



char- 
chain 
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Table 16. Communication Table [NPTRC2,35)] 
(Part 2 of 3) 



• Table 16. Communication Table [NPTR(2,35)] 
(Part 3 of 3) 



1— i- 



^-_| 

7|NADC0N index for 
I last statement 
j number 



K-4- 



H- i- 



101 



5|NADC0N index for 
I first temporary 
I (phase 20) 



6 I Maximum line count 



8 j Type of text 
j (phase 10) ; Pointer 
jto next phase 10 
I text item (phase 
j 15) ; Pointer to 
1 . QXX temporary 
j chain (phase 20) 



9 I Pointer to next 
j available phase 10 
j text entry 



Pointer to 5-char- 
acter symbol chain 



Pointer to 6-char- 
acter symbol chain 



Pointer to last 
dictionary entry 
in stmt number 
chain (XREF — phase 
10) ; Number of reg- 
isters reserved for 
RX branches (phases 
20 and 25) 



Pointer to last 
available phase 10 
text entry 



Name of routine 
(subprogram/main program) 



f— !■ — 
11 j Phase in control 
indicator 



1— +- 
12 



1-— h 
13 



m 



15 



16 



17 



K-4 

18 



1— + 

19 



Maximum no. of er- 
ror table entries 



END card indicator 
(phase 10) 



Pointer to 
parameters 



NADCON index for 
first parameter 
list 



Page count 



Current line count 



Relative location 
for register 13 



Active register: 
zero for reg 13, 
nonzero for reg 12 



■+ 



Trace switch; opti- 
mization downgrade 
switch 



Pointer to first 
card of source pgm 



Pointer to U-byte 
constant chain 



Pointer to 8-byte 
constant chain 



Pointer to 16-byte 
constant chain 



Pointer to state- 
ment number chain 



Number of branch 
table entries; rel- 
ative location of 
register 12 



NADCON index for 
statement number 
adcons 



21 



22 



1—4 

23 



24 



25 



20 



I— + 

26 



27 



f— t 



28 



1—4 



29 



K~4 



30 



31 



32 



33 



3a 



-4 



35 



Secondary entry 
points if nonzero 



Location counter 



Pointer to dic- 
tionary entry for 
IBCOM 



External function 
and/or CALL indi- 
cator 



-4- 



Program uses 
FLOAT/FIX or MOD 
function if non- 
zero; arithmetic 
interrupt indica- 
tor 



Pointer to first 
dictionary entry 



Pointer to DEFINE 
FILE text 



Pointer to literal 
constant chain 



Pointer to DIOCS 
entry 



Pointer to branch 
table chain 



BLOCK DATA sub- 
program switch 



FUNCTION SUB- 
PROGRAM switch 



Pointer to name- 
list text chain 



Size of constants 



Current displace- 
ment from active 
register (phase 
20) 



•4 



Relative location 
of adcon for first 
statement n\imber 



Number of times 
XREF buffer has 
been written out 
(phase 10) 



NADCON index for 
first COMMON area 



Actual number of 
error table entries 



Pointer to end of 
statement number 
chain 



Optimization level 



Pointer to COMMON 
chain 



Pointer to EQUIVA- 
LENCE chain 



Pointer to data 
text chain 



Pointer to normal 
text chain 



Pointer to next 
available informa- 
tion table entry 



Pointer to end of 
information table 



SUBROUTINE SUB- 
PROGRAM switch 



Pointer to format 
text chain 



Size of variables 



Adcon entry number 



Delete/error switch 
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Table 17. Keyword Pointer Table 



j Character 

1 (1 byte) 

1 


_J 


— — 1 

Niimber^L 
(1 byte) 


r ■ 

Displacement 2 

(2 bytes) 


r 

1 A 


-T~ 





2 







1 B 






2 


12 


1 c 






5 


34 


! D 






8 


84 


1 E 






5 


175 


1 F 






3 


220 


1 G 






1 


244 


1 H 












i I 






3 


250 


1 J 












1 K 












1 L 






2 


28 6 


1 M 






1 


312 


1 N 






2 


318 


1 












i p 






3 


336 


1 Q 












1 R 






5 


357 


1 s 






3 


399 


1 T 






2 


428 


1 u 












I V 












1 w 






1 


447 


1 X 












1 Y 












1 z 

L 


^J__ 












r ■ 

j ^This field contains the 
1 words beginning with th€ 
1 character. 

1 2Thi:S field contains the 
1 from the beginning of tl 
] for the group of keyworc 
i with the character. 




number of key- 
; associated 

displacement 
le keyword table 
is associated 



Table 18. Keyword Table (Part 1 of 2) 

r T T 1 

I Length-1^1 Key Word^ |Code3 | 



h 



■I 



J 5 1 ASSIGN 




1 1 


I 1 jAT 




1 9 


1 8 1 BACKSPACE 




1 2 


\ 8 1 BLOCKDATA 




1 3 


1 7 1 CONTINUE 




1 5 


J 5 1 COMMON 




1 7 


1 3 1 CALL 




1 S 


J 14 JCOMPLEXFUNCTION 




1 ^ 


1 6 1 COMPLEX 




1 6 


1 8 1 DIMENSION 




1 14 


1 3 1 DATA 




1 17 

1 


1 1 1 

1 22 JDOUBLEPRECISIONFUNCTIONI 10 
1 1 ' 


1 14 IDOUBLEPRECISION 




1 11 


J 1 jDO 




1 18 


1 9 1 DEFINEFILE 




1 13 


1 6 1 DISPLAY 




1 15 


1 4 1 DEBUG 




1 16 


1 10 1 EQUIVALENCE 




1 19 


1 6 lENDFILE 




1 21 


] 3 lEND (group mark) 


* 


1 23 


1 4 I ENTRY 




1 22 


1 7 1 EXTERNAL 




1 20 


1 5 1 FORMAT 
L _ JL 




1 25 

_L 


r - 

J ^This part of the entry for each keyword 

1 is one byte in length and contains a 

j value equal to the niamber of characters 

j in that keyword minus one. 

] 2This part of the entry for each keyword 

] contains an image of that keyword at one 

i byte per character. 

1 3This part of the entry for each keyword 

I is one byte in length and contains the 

J classification code for that keyword. 

J *Represented in hexadecimal as 'C5D5C4 4F' 
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Table 18. Keyword Table (Part 2 of 2) 
Key Word a 



r ■ T- 

I Length-1=>-| 
J. +. 



T 1 

|Code3 I 
4 ^ 



1 7 1 FUNCTION 






1 24 


1 3 1 FIND 






1 12 


1 3 1 GOTO 






1 27 


1 7 1 IMPLICIT 






1 29 


1 14 1 INTEGERFUNCTION 




1 28 


1 6 1 INTEGER 






1 30 


1 lU 1 LOGICAL FUNCTION 




1 33 


1 6 1 LOGICAL 






1 35 


1 3 1 MOVE 






1 34 


1 7 1 NAMELIST 






1 36 


1 5 1 NORMAL 






1 37 


1 4 1 PAUSE 






1 38 


j 4 1 PRINT 






1 39 


1 U 1 PUNCH 






1 40 


1 3 1 READ 






1 44 


1 5 1 RETURN 






1 43 


1 5 1 REWIND 






1 42 


1 11 1 REALFUNCTION 






1 41 


1 3 1 REAL 






1 45 


1 3 1 STOP 






1 48 


1 9 1 SUBROUTINE 






1 46 


1 8 1 STRUCTURE 






1 47 


1 7 1 TRACEOFF 






1 49 


1 6 1 TRACEON 






1 50 


j 4 1 WRITE 

L X _ _ _ 






1 51 


1 ^This part of the entry for each keyword 

1 is one byte in length and contains a 

1 value equal to the number of characters 

] in that keyword minus one, 

1 ^This part of the entry for each keyword 

i contains an image of that keyword at one 

1 byte per character. 

1 3This part of the entry for each keyword 

1 is one byte in length and contains the 

I classification code for that keyword. 



NADCON TABLE 



The NADCON table, built by PHAZ15 and 
CORAL and partially overwritten by phase 
20, contains: 



1. Parameter list pointers. 

2. Adcons for local variables and 
constants. 

3. Adcons for variables in COMMON and for 
those equivalenced into COMMON. 

4. Adcons for external references. 



The information in the table is used by 
CORAL and phase 25. Each table entry is 
one word in length; the format of the table 
is shown in Table 19. 



Table 19. NADCON Table 

r " 1 

I Parameter list pointer entries (one word 
]per entry) 



^ 

jAdcon entries for local variables and 
I constants (one word per entry) 



^ _ 

jAdcon entries for variables in COMMON and 
I those equivalenced into COMMON (one word 
I per entry) 



]Adcon entries for external references 
I (one word per entry) 

L . 



Parameter entries are created by PHAZ15. 
Each entry is a pointer to the dictionary 
entry for the parameter. Indicators denote 
ends of parameter lists and also parameters 
shared by more than one function or subrou- 
tine call. 



Adcon entries are created by CORAL and 
then inserted by CORAL into the adcon por- 
tion of the object module (see Figure 9). 
Pointers to temporaries are created by 
phase 20 and placed in the portion of the 
table used previously by CORAL, 



Phase 25 inserts the parameters and tem- 
poraries into the object module. The 
right-hand portion of Figure 9 indicates 
the sequence in which storage is assigned 
in the object module and the data which is 
entered into that storage. 
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INFORMATION TABLE 



The information table (referred to as 
NDICT or NDICTX) is constructed by Phase 10 
and modified by subsequent phases. This 
table contains entries that describe the 
operands of the source module. The infor- 
mation table consists of five components: 
dictionary, statement number/array table, 
common table, literal table, and branch 
table. 



INFORMATION TABLE CHAINS 



The information table is arranged as a 
number of chains. A chain is a group of 
related entries, each of which contains a 
pointer to another entry in the group. 
Each chain is associated with a component 
of the information table. 



• One literal table chain for entries 
that describe literal constants used as 
arguments in CALL statements. 

• One branch table chain composed of 
entries for statement numbers appearing 
in computed GO TO statements. 

Entries describing the various operands 
of the source module are developed by Phase 
10 and placed into the information table in 
the order in which the operands are encoun- 
tered during the processing of the source 
module. For this reason, a particular 
chain' s entries may be scattered throughout 
the information table and entries describ- 
ing different types of operands may occupy 
contiguous locations within the information 
table. Figure 10 illustrates this concept. 



CHAIN CONSTRUCTION 



The information table can contain the 
following chains: 

• A maximum of nine dictionary chains: 
one for each allowable FORTRAN variable 
length (1 through 6 characters) and one 
for each allowable FORTRAN constant 
size (4, 8, or 16 bytes). Each dic- 
tionary chain for variables contains 
entries that describe variables of the 
same length. Each dictionary chain for 
constants contains entries that de- 
scribe constants of the same size. 

• One statement number/array chain for 
entries that describe statement 
numbers . 

• Two common table chains: one for 
entries describing common blocks and 
their associated variables, and one for 
entries describing equivalence groups 
and their associated variables. 



The construction of a chain requires : 
(1) initialization of the chain, and (2) 
pointer manipulation. Chain initialization 
is a two-step process: 

1. The first entry of a particular type 
(e.g., an entry describing a variable 
of length one) is placed into the 
information table at the next avail- 
able location. 

2. A pointer to this first entry is 
placed into the communication table 
entry (see "Commini cation Table") 
reserved for the chain of which this 
first entry is a member. 

Subsequent entries are linked into the 
chain via pointer manipulation, as de- 
scribed in the following paragraphs. 

The communication table entry containing 
the pointer to the initial entry in the 



JL.JL 



\ 



/ / 
/ / 



I I I I I STMT/ 1 I STMT/ j j j | | 
I DICT I COMM I BRAN | DICT | ARRAY j LIT j ARRAY j CCMM | LIT j BRAN j DICT | 
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Figure 10. Information Table Chains 
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chain is examined and the first entry in 
the chain is obtained. The item that is to 
be entered is compared to the initial 
entry. If the two are equal, the item is 
not re-entered; if they are unequal, the 
first entry in the chain is checked to see 
if it is also the last. (An entry is the 
last in a chain if its "chain" field is 
zero. ) 

If the chain entry under consideration 
is the last in the chain, the new item is 
entered into the information table at the 
next available location, and a pointer to 
its location is placed into the chain field 
of the last chain entry. The new entry is 
thereby linked into the chain and becomes 
its last member. 

If the entry under consideration is not 
the last in the chain, the next entry is 
obtained by using its chain field. The 
item to be entered is compared to the entry 
that was obtained. If the two are equal, 
the item is not re-entered; if they are 
unequal, the entry under consideration is 
ch€!cked to see if it is the last in the 
chain; etc. 

This process is continued until a com- 
parable entry is found or the end of the 
chain is found. If a comparable entry is 
found, the item is not reentered. If the 
new item is not found in the chain, it is 
then linked into the chain. 



OPERATION OF INFORMATION TABLE CHAINS 



The following paragraphs describe the 
operation of the various chains in the 
information table. 



Dictionary Chain Operation 



The operation of a dictionary chain is 
based upon "balanced tree" notation. This 
notation provides two chains, high and low 
(with a common midpoint), for the entries 
describing variables of the same length or 
constants of the same size. The initial 
midpoint is the first entry placed into the 
information table for a variable of a par- 
ticular length or a constant of a particu- 
lar size. When two entries have been made 
on the high side of the midpoint, the first 
entry on the current midpoint's high-chain 
becomes the new midpoint. Similarly, when 
two entries have been made on the low side 
of the midpoint, the first entry on the 
cuirrent midpoint' s low-chain becomes the 
new midpoint. 



A change of midpoint for a variable of a 
particular length or a constant of a parti- 
cular size causes a pointer to the new mid- 
point to be recorded in the communication 
table. The following example illustrates 
the manner in which phase 10 employs the 
balanced tree notation to construct a dic- 
tionary chain. 

Assume that the following variables 
appear in the source module in the order 
presented. 



D 



E 



B 



When phase 10 encounters the variable D, 
it constructs a dictionary entry for it 
(see "Dictionary"), places this entry at 
the next available location in the informa- 
tion table, and records a pointer to that 
entry into the appropriate field of the 
communication table (see "Communication 
Table"). The entry for D is the initial 
midpoint for the chain of entries describ- 
ing variables of length one. (When a dic- 
tionary entry is placed into the informa- 
tion table, both the high- and low-chain 
fields of that entry are zero. ) 

When phase 10 encounters the variable C, 
it constructs a dictionary entry for it. 
Phase 10 then obtains the dictionary entry 
that is the initial midpoint and compares c 
to the variable in that entry. If the two 
are unequal, phase 10 determines whether or 
not the variable to be entered is greater 
than or less than the variable in the 
obtained entry. In this case, C is less 
than D in the collating sequence, and, 
therefore, phase 10 examines the low-chain 
field of the obtained entry, which is that 
for D. This field is zero, and the end of 
the chain has been reached. Phase 10 
places the entry for C into the next avail- 
able location in the information table and 
records a pointer to that entry in the low- 
chain field of the dictionary entry for D, 
The entry for c is thereby linked into the 
chain. 

When the variable E is encountered, 
phase 10 carries out essentially the same 
procedure;' however, because E is greater 
than D, phase 10 examines the high-chain 
field of the entry for D. It is zero, 
which denotes the end of the chain. There- 
fore, phase 10 places the dictionary entry 
for E into the next available location in 
the information table and records a pointer 
to that entry in the high-chain field of 
the dictionary entry for D. 

When the variable F is encountered, 
phase 10 constructs a dictionary entry for 
it and compares it to the variable in the 
entry that is the common starting point for 
the chain. Because F is greater than D, 
phase 10 examines the high-chain field of 
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the entry for D. This field is not zero 
and, hence, the end of the chain has not 
yet been reached. _ Phase 10 obtains the 
entry (for E) at the location pointed to by 
the nonzero chain field (of the entry for 
D) and compares F to the variable in the 
obtained entry. The variable F is greater 
than the variable E. Therefore, phase 10 
examines the high-chain field of thei entry 
for E. This field is zero and the end of 
the chain has been reached. Phase 10 
places the entry for F into the next avail- 
able location in the information table and 
records a pointer to that entry in the 
high-chain field of the entry for E, Since 
two entries have now been made on the high 
side of the current midpoint, the first 
variable on D's high-chain beccmes the new 
midpoint. 



Phase 10 carries out similar procedures 
to link the entries for the variables A and 
B into the chain. 



(If one of the comparisons made between 
a variable to be entered into the dic- 
tionary and a variable in an entry already 
in the dictionary results in a match, the 
variable has previously been entered and is 
not reentered. ) 



Statement Number Chain Operation 



The statement number chain constructed 
by phase 10 is linear; that is, each state- 
ment number entry (see "Statement Number/ 
Array Table") is pointed to by the chain 
field of the previously constructed state- 
ment number entry. The first statement 
number entry is pointed to by a pointer in 
the communication table. 



To construct the statement number chain, 
phase 10 places the statem.ent number entry 
constructed for the first statement number 
in the module into the next available loca- 
tion in the information table. It records 
a pointer to that entry in the appropriate 
field of the communication table. (When a 
statement number entry is placed into the 
information table, its chain field is 
zero. ) Phase 10 links all other statement 
number entries into the chain by scanning 
the previously constructed statement number 
entries (in the sequence in which they are 
chained) until the last entry is found. 
The last entry is denoted by a zero chain 
field. Phase 10 then places the new entry 
at the next available location in the 
information table and records a pointer to 
that entry in the zero chain field of the 
last entry in the chain. The new entry is 
thereby linked into the chain and becomes 
its last member. (Throughout the construc- 
tion of the statement number chain, phase 
10 makes comparisons to insure that a 
statement number is entered only once. ) 



Figure 11 illustrates the manner in 
which the entries for the variables are 
chained after the entry for B has been 
linked into the chain. 



Common Chain Ope ration 



1st and 
3rd mid- 
points 




2nd 
mid-point 



Note; High and low chains are maintained 
for all entries. When the entry for F is 
made, the mid-point shifts from D to E. 
When the entry for A is made, the mid- 
point shifts from E to D. 

L ^ 

Figure 11. Dictionary Chain 



The chain constructed by phase 10 due to 
COMMON statements appearing in the source 
module is bi-linear; that is, phase 10 
links together: 



1. The individual COMMON block name 

entries (see "COMMON Table") that it 
develops for the COMMON block names 
appearing in the module. 



2. The dictionary entries (see "Dic- 
tionary") that it develops for the 
variables appearing in a particular 
common block. (The dictionary entry 
for the first variable appearing in a 
COMMON block is also pointed to by the 
COMMON block name entry for the COMMON 
block containing the variable. ) 
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To construct the COMMON chain, phase 10 
places the COMMON block name entry that it 
constructs for the first COMMON block name 
appearing in the module at the next avail- 
able location in the information table. It 
records a pointer to this entry in the 
appropriate field of the communication 
table. Phase 10 then obtains the first 
variable in the COMMON block, constructs a 
dictionary entry for it, places the entry 
at the next available location in the 
information table, and records a pointer to 
that entry in the PI and P2 field of the 
COMMON block name entry for the COMMON 
block containing the variable. Phase 10 
obtains the next variable in the common 
block, constructs a dictionary entry for 
it, places the entry in the information 
table, records a pointer to that entry in 
the COMMON chain field of the dictionary 
entry constructed for the variable encoun- 
tered immediately prior to the variable 
under consideration (this entry location is 
obtained from the P2 field of the COMMON 
block name entry) , and records a pointer to 
the information table for the new COMMON 
variable in the P2 field. Thus, the P2 
field of the COMMON block name entry always 
contains a pointer to the information table 
entry for the last variable of a given COM- 
MON block. Phase 10 obtains the next vari- 
able in the COMMON block, etc. 



variable associated with the second mention 
of a COMMON block name to the dictionary 
entry for the first variable associated 
with the second mention of that name; etc. 

If a third mention of a particular COM- 
MON block name is encountered, phase 10 
processes the associated variables in a 
similar manner. It links the dictionary 
entries constructed for these variables as 
extensions to the dictionary entries devel- 
oped for the variables associated with the 
second mention of the COMMON block name. 



Equivalence Ch ain Operation 



The chain constructed by phase 10 due to 
EQUIVALENCE Statements appearing in the 
source module is also bi-linear. Phase 10 
links together: 



The individual equivalence group 
entries (see "COMMON Table") that it 
constructs for the equivalence groups 
appearing in the module. 



When phase 10 encounters a second unique 
COMMON block name, it constructs a COMMON 
block name entry for it, places the entry 
in the information table, and records a 
pointer to that entry in the chain field of 
the last COMMON block name entry, which is 
found by scanning the chain of such entries 
until a zero chain field is detected. 
Phase 10 then links the dictionary entries 
that it constructs for the variables 
appearing in the second COMMON block into 
the chain in the previously described 
manner. 



If a COMMON block name is repeated in 
the source module a number of times, phase 
10 constructs a COMMON block name entry 
only for the first appearance^ However, it 
does include as members of the COMMON block 
the variables associated with the second 
and subsequent mentions of the COMMON block 
name. Phase 10 constructs a dictionary 
entry for the first variable associated 
with the second mention of the COMMON block 
name and places it into the information 
table. It then records a pointer to the 
dictionary entry for the new variable in 
the COMMON chain field of the last variable 
associated with the first mention of the 
COMMON block name. Phase 10 links the dic- 
tionary entry it constructs for the second 



The equivalence variable entries (see 
"COMMON Table") that it constructs for 
the variables appearing in a particu- 
lar equivalence group. (The equiva- 
lence variable entry for the first 
variable appearing in an equivalence 
group is pointed to by the equivalence 
group entry for the group containing 
the variable. ) 



The construction of the equivalence 
chain by phase 10 parallels its construc- 
tion of the COMMON chain. It links the 
equivalence group entries in the same man- 
ner as it does COMMON block name entries, 
and links equivalence variable entries in 
the same manner as the dictionary entries 
for the variables in a COMMON block. (The 
location of the last EQUIVALENCE group 
entry generated is recorded in the appro- 
priate field of the communication table; 
the location of the last EQUIVALENCE vari- 
able entry generated is recorded locally in 
the keyword subroutine that processes the 
EQUIVALENCE statement). 



Literal Constant Chain Operation 



The chain constructed by phase 10 for 
the literal constant information appearing 
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in the source module is linear. The liter- 
al constants are chained in reverse order 
of occurrence. Phase 10 records a pointer 
to the most recent literal constant entry 
generated. As each new entry is made, it 
is chained to the previous entry and it, in 
turn, is recorded as the most recent. 



Branc h Table C hain Operation 



The phase 10 construction of the branch 
table chain parallels that of the statement 
number chain. It records a pointer to the 
first branch table entry (see "Branch 
Table") that is placed into the information 
table in the appropriate field of the com- 
munication table. In the chain field of 
the previously developed branch table 
entry, phase 10 records a pointer to the 
location in the information table for any 
new branch table entry. Unlike statement 
number entry processing, no label compari- 
son is necessary. Thus, scanning the chain 
is avoided by recording the location of the 
last branch table entry in the P2 field of 
the first Initial Branch Table entry. 



I ! 



4 bytes 

High-chain field 



Low- chain field 



h 



]Mode field 



I Type field 



I Used by | 

I subroutine j 

I STALL- I 

JIEKGST I PI field 



COMMON displacement field 



JByte A I Byte B j 
usage field) usage field jDIS field 



]SF field I COMMON chain field 

|. . X ^ ^ 

I I Used for XREF 3 Name field 

I processing j 
' |. X ^ 

J Name field 

^ ^ 

3 Note ; This field exists only if the XREF 
I option is used (See figure 15). 

L J 

• Figure 12. Format of Dictionary Entry for 
Variable 



INFORMATION TABLE COMPONENTS 



The following text describes the con- 
tents of each component of the information 
table and presents illustrations of phase 
10 formats of the entries for each com- 
ponent. Modifications made to these 
entries by subsequent phases of the compil- 
er are also illustrated. 



Dictionary 



The dictionary contains entries that 
describe the variables and constants of the 
source module. The information gathered 
for each variable or constant is derived 
from an analysis of the context in which 
the variable or constant is used in the 
source module. 



VARIABLE ENTRY FORMAT ; The format of the 
dictioriary entries constructed by phase 10 
for the variables of the source module is 
illustrated in Figure 12. 



High-Chain Field ; The high-chain field is 
used to maintain linkage between the 
various entries in the chain. It contains 
either a pointer to an entry that collates 
higher in the collating sequence or an 
indicator (zero) , which indicates that 
entries in the chain that collate higher 
than itself have not yet been encountered. 



Byte A Usage Field ; This field is con- 
tained in the first byte of the second 
word. This field indicates a portion of 
the characteristics of the variable for 
which the dictionaty entry was created. 
The byte A usage is divided into eight sub- 
fields, each of which is one bit long. The 
bits are numbered from through 7. Figure 
13 indicates the function of each subfield 
in the byte A usage field. 



Byte B Usage Field; The byte B usage field 
is contained in the second byte of the 
second word. This field indicates addi- 
tional characteristics of the variable 
entered into the dictionary. It is divided 
into eight subfields, each of which is one 
bit long. The bits are numbered from 
through 7. Figure 14 illustrates the func- 
tion of each subfield in the byte B usage 
field. 
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r T 

Subfield | Function 



Bit "on* j variable is structured 



Bit 1 • on' i symbol referred to 



Bit 2 'on* j variable is in COMMON 



Bit 3 'on' ] not used 



Bit lA 'on* ] variable is equated 



Bit 5 ' on' I variable has appeared in an 

i equivalence group that has 

5 been processed by subrou- 

1 tine STALL- lEKGST (used by 

I phase 15) 



Bit 6 'on' ] variable is an external 
j function name 
4- 



Bit 7 'on' j variable appears in type 
I statement 

L .^ ^JL_^ J 

Figure 13. Function of Each Subfield in 
the Byte A Usage Field of a 
Dictionary Entry for a Variable 
or Constant 



r T 

I Subfield 1 Function 



PIS Field; The DIS field contains either 
the displacement of a structured variable 
from the head of its structure group or the 
number of dummy arguments for a statement 
function name. If the variable is neither 
structured nor a statement function name, 
this field contains a count of the number 
of times the variable appears in the source 
program. 



i L ow - Chain Field ; The low-chain field is 
used to maintain linkage between the 
various entries in the chain. It contains 
either a pointer to an entry that collates 
lower in the collating sequence or an indi- 
cator (zero) , which indicates that entries 
in the chain that collate lower than itself 
have not yet been encountered. 



Mode/Type Field ; The mode/type field is 
divided into two subfields, each two bytes 
long. The first two bytes (mode subfield) 
are used to indicate the mode of the vari- 
able (e.g., integer, real); the second two 
bytes (type subfield) are used to indicate 
the type of the variable (e.g., array, 
external function). Both the mode and type 
are numeric quantities and correspond to 
the values stated in the mode and type 
tables (see Tables 20 and 21), 



Bit 'on' 



Bit 1 'on' 



Bit 2 'on' 



Bit 3 'on' 



Bit U 'on' 



Bit 5 'on* 



Bit 6 'on' 



H- 



Bit 7 'on' 



L 



variable is "call by value" 
parameter 



variable is "call by name' 
parameter 



variable is used as an 
argument 



variable has appeared in a 
previous DATA statement 
(phase 15) 



not used 



variable is used as a 
subscript 



variable is in COMMON, or 
in an equivalence group and 
has been assigned a rela- 
tive address (phase 15) 



variable appears in DATA 
statement 



Figure 14. Function of Each Subfield in 
the Byte B Usage Field of a 
Dictionary Entry for a Variable 



PI Field ; The PI field contains either a 
pointer to the dimension information in the 
statement number/array table if the entry 
is for an array (i.e., a dimensioned vari- 
able), or a pointer to the text generated 
for the statement function (SF) if the 
entry is for an SF name. If the entry is 
neither for the name of an array nor the 
name of a statement function, the field is 
zero. 



COMM ON Displacement Field; The displace- 
ment of the variable, if it is in COMMON, 
is placed in this field by Phase 10. This 
information will be moved to the DIS field 
by CORAL and replaced with a pointer to the 
dictionary entry for its COMMON block. 



SF Field; The SF field contains STORE- 
FETCH information for the variable. If the 
variable is stored into, bit 0=1; if the 
variable is fetched, bit 1=1. 
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Table 20. Operand Modes 





Internal 




Representation 


Mode of Operand 


(in hexadecimal) 

L 


" - ■' — T 


Logical*! 


2 


Logical* 4 


3 


Integer* 2 


H 


Integer 


5 


Real*8 ; 


6 


Real*4 


7 


Complex*16 


8 


Complex* 8 


9 


Literal 


A 


Statement number 


B 


Hexadecimal 


C 



Namelist 
Repeat constant 



Table 21. 



Operand Types 





Internal | 




I Representation | 


Type of Operand 

_ _ — — — _j 


(in hexadecimal) } 
L _ _J 




_ _ -^ 


Scalar 


1 


Dummy scalar 


1 1 


Array 


2 1 


Dummy array 


3 1 


External function 


^ 1 


Constant 


5 ] 


Statement function 


6 1 


Negative scalar 


8 1 


Negative dummy scalar 


9 1 


Negative array 


A j 


Negative dummy array 


B j 


Negative external 


c 1 


function 




Negative constant 


D 1 


Negative statement 


E 1 


function 




QXX temporary 


F 1 


(created by text 




optimization) 





COMMON Chain Field ; This field is used to 
maintain linkages between the variables in 
a COMMON block. It contains a pointer to 
the dictionary entry for the next variable 
in the COMMON block. (If the variable for 
which a dictionary entry is constructed is 
not in COMMON, this field is not used.) 

Name Field ; This field contains the name 
of the variable (right- justified) for which 
the dictionary entry was created. 



MODIFICATIONS TO DICTIONARY ENTRIES FOR 
VARIABLES; During compilation, certain 
fields of the dictionary entries for 



variables may be modified. The following 
examples illustrate the formats of dic- 
tionary entries for variables at various 
stages of phase 10 and phase 15 processing, 
Only changes are indicated; * stands for 
unchanged. 



Dict ionary Ent ry for Variable After Prep- 
aration for XREF Processing ; The format of 
a dictionary entry for a variable after 
subroutine CSORN-IEKCCR processing is 
illustrated in Figure 15. 



XREF Buffer Pointer — L ast Entry : This 
field contains a pointer to the most recent 
XREF buffer entry for the symbol. 



XREF Buffer C oun t; This field contains a 
count of the number of times the XREF buff- 
er has been written out on SYSUT2 at the 
time that this dictionary entry is modified 
by subroutine CSORN-IEKCCR. 



■4 bytes- 



r— 

I !* 



■T — 

I* 



I* 



j. ± ^_. 

] XREF buffer pointer- | * 
I last entry | 

L JL_- 



I XREF buffer count 
I 



JXREF buffer pointer- 
I first entry 



• Figure 15. Format of Dictionary Entry for 
Variable After CSORN-IEKCCR 
Processing for XREF 



XREF Buffer Pointer — First Entry ; This 
field contains a pointer to the first XREF 
buffer entry for this symbol. 

Dictionary Entry for Variable_ After Dic- 
tionar y Rechaininq; The format of a dic- 
tionary entry for a variable after the dic- 
tionary has been rechained during subrou- 
tine STALL-IEKGST is illustrated in Figure 
16. 
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H bytes 

New chain field 



1* 



• Figure 16. Format of Dictionary Entry for 
Variable After Rechaining 



Dictionary Entry for yariable_Af ter Co- 
ordinate Assignment ; The format of a dic- 
tionary entry for a variable after co- 
ordinate assignment by the STALL-IEKGST 
subroutine is illustrated in Figure 17. 



• 4 bytes- 



r 

I I* 
I- 



I-— - 
I* 
H" - 



j. ^_. 

I coordinate I ♦ 
I number for | 
j variable | 

1— ■^- 



■T— 
I* 



I J- 



j. _. 

i. J 

I* 

L . 

Figure 17. Format of Dictionary Entry for 
Variable After Coordinate 
Assignment 



■ U bytes- 



1 '1 

1 H 

-I k- 

I V 

-! h 



i Displacement from 
(start of COMMON 
I block 

.X 



] COMMON block pointer 
j. 

3* 

^ 



• Figure 18. Format of Dictionary Entry for 
Variable After COMMON Block 
Processing 



■ 4 bytes- 



^ „ ^ ^ _ ^ 

J I [Displacement from 

3 I I base register 

^ ± X 

] Pointer to entry containing 

J pointer to address constant 

j for variable 

^ ^ ^ 



^ I 



^ I 



• Figure 19. Format of Dictionary Entry for 
a Variable After Relative 
Address Assignment 



Dictionary Entry for Variable After Rela- 
tive Address Assignment; The format of a 
dictionary entry for a variable after rela- 
tive address assignment is illustrated in 
Figure 19. 



Dictionary Entry for Variable After COMMON 
Block Processing ; The format of a dic- 
tionary entry for a variable after COMMON 
block processing is illustrated in Fig- 
ure 18. 



CONSTANT ENTRY FORMAT ; The format of the 
dictionary entries constructed by phase 10 
for the constants of the source module is 
illustrated in Figure 20. 
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The format of a dictionary entry for a 
constant is the same as for a variable. 
The changes the entry undergoes during 
processing are the same except that bytes 3 
and 4 of word two contain a displacement 
from an associated address constant and a 
constant does not undergo XREF processing. 
Also, for constants referred to implicitly, 
PHAZ15 sets a referenced bit to on. (Bit 1 
in the byte A usage field; see Figure 13, ) 



I 



4 bytes 

Backward chain field 



I ! 



k- 



Forward chain field 



Mode field 



r ~T- 

jused by | 

j subroutine | 
I STALL- I 
I lEKGST j 

I- 



\ Type field 

.X . 



|. ^ ^ 

I Byte A I Byte B | | 

I Usage field] Usage field) Used by phase 15 ] 

_• .-x X i 



Constant 


field 


constant 


field 


Constant 


field 


constant 


field 



• Figure 20. Format of Dictionary Entry for 
Constant 



■ 4 bytes- 



Chain Field 


Byte 
Usage 


T T T 

A 1 Byte B I Used by j Used by 
1 Usage J phase 20 j phase 20 

± A. ± 


Pointer field 


Image field 


Used for XREF processing 


Used for XREF processing 


Used for XREF processing 


Used by phase 20 


Note: 


This field exists only if the XREF 
option is used (See figure 24). 



Figure 21. Format of a Statement Number 
Entry 



Byte_A_y sac[e_Field : This field is con- 
tained in the first byte of the second 
word. This field indicates a portion of 
the characteristics of the statement number 
for which the entry was created. The byte 
A usage field is divided into eight sub- 
fields, each of which is one bit long. The 
bits are numbered from through 7. Figure 
22 indicates the function of each subfield 
of this field. 



Statement Number/Array Table 



The statement number/array table con- 
tains statement number entries, which 
describe the statement numbers of the 
source module, and dimension entries, which 
describe the arrays of the source module. 



§Y;^e.._B_Usage _Field ; This field is con- 
tained in the second byte of the second 
word. The byte B usage field indicates 
additional characteristics of the statement 
number for which the entry was constructed. 
The byte B usage field is divided into 
eight subfields, each of which is one bit 
long. The bits are numbered through 7. 
Figure 23 indicates the function of each 
subfield in the byte B usage field. 



STATEMENT NUMBER ENT RY FORMAT ; The format 
of the statement number entries constructed 
by phase 10 is illustrated in Figure 21. 



Chain Field ; The chain field is used to 
maintain linkage between the various 
entries in the chain. It contains either a 
pointer to the next statement number entry 
in the chain or an indicator (zero), which 
indicates the end of the statement number 
chain. 



Pointer Field ; If the entry is for the 
first statement niomber, this field contains 
a pointer to the last statement number 
entry. Otherwise, the field contains 
zeroes. 



Image Field; This field contains the 
binary representation of the statement num- 
ber for which the entry was created. 
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1 Subfield 


1 


Function 


1 Bit 





•on' 


J 

1 


statement number defined 


1 Bit 


1 


'on* 


1 


statement number referred 
to 


1 Bit 


2 


•on' 


1 

1 


referred to in an ASSIGN 
statement 


1 Bit 


3 




1 
1 


not used 


1 Bit 


4 


•on' 


1 

n 


statement number of a FOR- 
MAT statement 


1 Bit 


5 


•on^ 


1 ' 

1 


statement number of a GO 
TO, PAUSE, RETURN, STOP, or 
DO statement 


J Bit 


6 


•on' 


1 
\ 


statement number used as an 
argument 


1 Bit 


7 


•on* 


1 


statement number is the 
object of a branch 



4 bytes- 



Figure 22. Function of Each Subfield in 
the Byte A Usage Field of a 
Statement Number Entry 



MODIFICATIONS TO STATEMENT NUMBER ENTRIES : 
During the processing of subroutines 
LABTLU-IEKCLT and STALL- lEKGST in phase 10, 
phases 15, 20, and 25, each statement num- 
ber entry created by phase 10 is updated 
with information that describes the text 
block associated with the statement number. 
During phase 10, if the XREF option is 
selected, subroutine LABTLU-IEKCLT makes 
changes in statement number dictionary 
entries for later use by subroutine XREF- 
lEKXRF (see Figure 24). 



j subfield 
1" 



Function 



Bit •on* 



Bit 1 



Bits 2-5 



Bit 6 'on' 



Bit 7 "on' 



statement number is within 
a DO loop and is trans- 
ferred to from outside the 
range of the DO loop 



compiler generated state- 
ment number 



not used 



statement number appears in 
END or ERR parameter of 
READ statement 



statement number is used in 
a computed GO TO statement 



Figure 23. Function of Each Subfield in 
the Byte B Usage Field of a 
statement Number Entry 



^ 

i "* 


\* 


T T T 

1 * 1* 1* 
± A. ± 


\* 


1* 


1 XREF 


buffer pointer — last entry 


jXREF 


— r~ ~ — 

buffer count | XREF buffer pointer — 

1 first entry 

J. 


1 Definition field 


1* 


{sequence chain field 

L 



Figure 24. Format of a Dictionary Entry 

for Statement Number After Sub- 
routine LABTLU-IEKCLT Proc- 
essing for XREF 



XREF Buffer Ppinter — Last Entry ; This 
field contains a pointer to the most recent 
XREF buffer entry for this statement num- 
ber, unless this dictionary entry is a 
definition of a statement number. If this 
dictionary entry is a definition of a sta- 
tement number, this field is not used. 



XREF Buffer Count ; This field contains a 
count of the number of times the XREF buff- 
er has been written out on sysUT2 at the 
time this dictionary entry is modified by 
subroutine LABTLU-IEKCLT. 



XREF Buffer Pointer — First Entry : This 
field contains a pointer to the first XREF 
buffer entry for this statement number. 



Defini t ion_Fie Id : This field contains an 
ISN if this statement number dictionary 
entry corresponds to a definition of a 
statement numoer. The field contains -1 if 
the statement number has been previously 
defined. 



Sequenc e Cha in Field; This field chains 
the statement numbers in numerical order. 
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Figure 25 illustrates the format of a 
statement number entry after the processing 
of the STALL-IEKGST subroutine and phases 
15, 20, and 25, Only changes are indi- 
cated; ♦ stands for unchanged. 



. 4 bytes- 
New Chain field 



I" 



■T 

I Block 

I status 

I Field 

-X 



-T 

I Loop 
I number 



I j Address constant pointer field 
j. 

I* 



h- 



[Text pointer field 



I Loop 

i number ( 

I save area j 

J. _ x-_ 

I Forward connection field (ILEAD) 
|. , 

{Backward connection field (JLEAD) 



Block size field (BSZ) 
j. ^ 

I I* 



• Figure 25, Format of Statement Number 

Entry After the Processing of 
Phases 15, 20, and 25 



New Chain Field ; The new chain field con- 
tains a pointer to the entry for the state- 
ment number that is defined in the source 
module immediately after the statement 
number for which the statement niomber entry 
under consideration was constructed, (The 
STALL-IEKGST subroutine modifies the phase 
10 chain pointer when it rechains the 
statement number entries to correspond to 
the order in which statement niambers are 
defined in the source module,) This field 
is not modified by subsequent phases. 

Block Status Field; The block status field 
indicates the status of the text block 
associated with the statement number entry 
under consideration. The block status 
field is divided into eight subfields, each 
of which is one bit long. The bits are 
numbered through 7. Figure 26 indicates 
the function of each subfield in the block 
status field. 



Loop Number Field; The loop number field 
contains the number of the loop to which 
the text block (associated with the state- 
ment number entry under consideration) 
belongs. This field is set up and used by 
phase 20, Just before the loop number is 



assigned, this field contains a depth 
number. 



Back Dominator Fjeld ; The back dominator 
field contains a .pointer to the statement 
number entry associated with the back 
dominator of the text block associated with 
the statement number entry under considera- 
tion. This field, set up and used by phase 
20, occupies the address constant pointer 
field. 



-i r 

I I Subfield 



Function 



H 1-- 

I } Bit 

H I 

1 1 



I 1 



I Bit 1 



j j Bit 2 'on* 

H 1 



i Bit 3 'on' 



J. 

I Bit 4 



] Bit 5 'on' 



k 

j Bit 6 'on* 



Bit 7 



Used for various reasons 
by the routines that 
explore connections (e.g., 
the associated block has 
previously been considered 
in the search for the back 
dominator of the block) 



■^ 



the associated block exits 
from a loop 



the associated block is a 
fork (i.e,, it has two or 
more forward connections) 



same as bits and 1 



the associated block is in 
the current loop 



the associated block has 
been completely processed 
along the 0PT=2 path 



the associated block is an 
entry block 



Figure 26, Function of Each Subfield in 
the Block Status Field 



Address Constant Pointer Field; 



The 



address constant pointer field (after phase 
25 processing) contains either of the 
following: 

• An indication of a reserved register 
and a displacement, if branching opti- 
mization is being implemented and if a 
branch can be made to the text block 
(associated with the statement number 
entry under consideration) via an RX- 
format branch instruction (see the 
phase 20, "Branching Optimization"). 

• A pointer to the address constant re- 
served for the statement nvmiber (see 
Phase 25, "ADCON Table Entry 
Reservation" ) , 
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Text Pointer Field ; The text pointer field 
contains a pointer to the phase 15 text 
entry for the statement number with which 
the statement number entry under considera- 
tion is associated. This field is not used 
by phase 10; it is filled in by phase 15, 
and is unchanged by subsequent phases. 

For war d Conne ct ion_Field_(ILEAD) ; The for- 
ward connection field contains a pointer to 
the initial RMAJOR entry for the blocks to 
which the text block associated with the 
statement number entry under consideration 
connects. This field is set up by. phase 15 
and used by phase 20. A relative address 
of the block is stored in this field by 
phase 20, 



Backward Connection Field (JLEAD) 



The 



backward connection field contains a point- 
er to the initial CMAJOR entry for the 
blocks that connect to the text block asso- 
ciated with the statement number entry 
under consideration. This field is set up 
by phase 15 and used by phase 20, During 
phase 25 a relative location is stored in 
the field. 

DIM ENSION ENTRY FORMAT ; The format of the 
dimension entries constructed by phase 10 
is illustrated in Figure 27. 

Array Size Field; The array size field 
contains either the total size of the asso- 
ciated array or zero, if the array has 
variable dimensions. 



U bytes- 
Array size field 



l~- 



Dimension number 
field 



Element length field 



First subscript pointer field 



Second subscript pointer field 



Third subscript pointer field 



Fourth subscript pointer field 



Fifth subscript pointer field 



h- 



Sixth subscript pointer field 



Used only for variable 
dimensions 



• Figure 27. Format of Dimension Entry 



Dimension Number_Field: The dimension 
number field contains the number of dimen- 
sions (1 through 7) of the associated 
array. 



Element Length Field; The element length 
field contains the length of each element 
(first dimension factor) in the associated 
array. 

First Subs crip t P oint er Field; The field 
contains either a pointer to the dictionary 
entry for the second dimension factor, 
which has a value of D1*L (see "Appendix F; 
Address Computation for Array Elements"), 
or a pointer to the dictionary entry for 
the first subscript parameter used to 
dimension the associated array if that 
array has variable dimensions.. This field 
is not used if the associated array has a 
single non-variable dimension. 

Second Subscript Pointer Field ; This field 
contains either a pointer to the dictionary 
entry for the third dimension factor, which 
has a value of D1*D2*L, or a pointer to the 
second subscript parameter used to dimen- 
sion the associated array if that array has 
variable dimensions. This field is not 
used if the associated array has a single 
dimension, or has two non-variable 
dimensions. 

Third Subscript Pointer Field ; This field 
contains either a pointer to the dictionary 
entry for the fourth dimension factor, 
which has a value of D1*D2*D3*L, or a 
pointer to the third subscript parameter 
used to dimension the associated array if 
that array has variable dimensions. This 
field is not used if the associated array 
has fewer than three dimensions, or has 
three non- variable dimensions. 

Fourth Subscript Pointer Field ; This field 
contains either a pointer to the dictionary 
entry for the fifth dimension factor, which 
has a value of D1*D2*D3*DU*L, or a pointer 
to the dictionary entry for the fourth sub- 
script parameter used to dimension the 
associated array if that array has variable 
dimensions. This field is not used if the 
associated array has fewer than four dimen- 
sions, or has four non-variable dimensions. 

Fifth Subscript Pointer Field ; This field 
contains either a pointer to the dictionary 
entry for the sixth dimension factor, which 
has a value of D1*D2*D3*DU*D5*L, or a 
pointer to the dictionary entry for the 
fifth subscript parameter used to dimension 
the associated array if that array has 
variable dimensions. This field is not 
used if the associated array has fewer than 
five dimensions, or has five non-variable 
dimensions. 

Sixth Subscript Pointer Field ; This field 
contains either a pointer to the dictionary 
entry for the seventh dimension factor, 
which has a value of D1*D2*D3*DU*D5*D6*L, 
or a pointer to the dictionary entry for 
the sixth subscript parameter used to 
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dimension the associated array if that 
array has variable dimensions. This field 
is not used if the associated array has 
fewer than six dimensions, or has six non- 
variable dimensions. 



Pointer to Last Subscript Parameter ; This 
field contains a pointer to the dictionary 
entry for the seventh subscript parameter 
used to dimension the associated array if 
that array has variable dimensions. This 
field is not used if the associated array 
has fewer than seven dimensions, or has 
seven non-variable dimensions. 



■4 bytes- 



r 

L_ 


1 

Chain field | 

J 


1) Pi field 1 
1 _ _ _ _ _ _ J 


1 P2 field 1 

L _J 


r — — -i 

] Name field | 
I _ _ J 


r — 1 

1 Name field | 
1 J 


r 

(Character 
1 field 

L 


T 1 

Number | ISN field | 

1 1 

± J 



Figure 28, Format of a COMMON Block Name 
Entry 



COMMON Table 



The COMMON table contains: (1) COMMON 
block name entries, which describe COMMON 
blocks; (2) equivalence group entries, 
which describe equivalence groups; and (3) 
equivalence variable entries, which 
describe equivalence variables. 



MODIFICATIONS TO COMMON BLOCK .NAME ENTRIES : 
During compilation, certain fields of COM- 
MON block name entries may be modified. 
Figure 29 illustrates the format of a COM- 
MON block name entry after COMMON block 
processing by subroutine STALL-IEKGST. 
Only changes are indicated; ♦ stands for 
unchanged. 



COMMON BLOCK NAME ENTRY F ORMAT; The format 
of the COMMON block name entries con- 
structed by phase 10 is illustrated in 
Figure 28. 



Chain Field : The chain field is used to 
maintain linkage between the various common 
block name entries. It contains either a 
pointer to the next COMMON block name entry 
or an indicator (zero), which indicates 
that additional common blocks have not yet 
been encountered. 



■U bytes- 



Total size of COMMON block 



PI Field; The PI field contains a pointer 

to the dictionary entry for the first vari- • Figure 29. 

able in this COMMON block. 



Format of COMMON Block Name 
Entry After COMMON Block 
Processing 



P2 Field : The P2 field contains a pointer 
to the dictionary entry for the last vari- 
able in this COMMON block. 



Name Field ; The name field contains the 
name (right- justified) of the COMMON block 
for which this COMMON block name entry was 
constructed. 



Character .Number _Field : The character 
number field contains the number of charac- 
ters in the COMMON block name. 

ISN Field ; The ISN field contains the ISN 
assigned to the statement in which this 
COMMON" block name first occurs. 



EQUIVALENCE GROUP ENTRY FORMAT ; The format 
of the equivalence group entries con- 
structed by phase 10 is illustrated in 
Figure 30, 



Indicator Field ; The indicator field is 
nonzero if a variable in this group is sub- 
scripted and its dimension statement has 
not been processed. 

Chain Field; The chain field is used to 
maintain linkage between the various equiv- 
alence groups. It contains a pointer to 
the next equivalence group entry. 
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<- 



r — • T- 

I Indicator ] 
I field I 

L J.. 



■4 bytes 

Chain field 



PI field 

Used by phase 15 



ISN field 



Figure 30. Format of an Equivalence Group 
Entry 



PI Field ; The PI field contains a pointer 
to the equivalence variable entry for the 
first variable in the equivalence group or 
for the first variable in the COMMON block. 



ISN Field; The ISN field contains the ISN 
assigned to the statement in which any name 
of the EQUIVALENCE group first occurs. 

MODIOCATIONS_Tg_EQUIVALENCE_GROUP_ENTRIES 
During compilation, certain fields of 
equivalence group entries may be modified. 
Figure 31 illustrates the format of an 
equivalence group entry after equivalence 
processing by subroutine STALL- lEKGST. 
Only changes are indicated; * stands for 
unchanged. 



■ 4 bytes- 



H 



j.__-. ^ 

) Pointer to the "head" of the equivalence | 
I group I 



I" 



H 



Figure 31, Format of Equivalence Group 
Entry After Equivalence 
Processing 



EQUIVALENCE VARIABLE ENTRY FORMAT; The 
format of the equivalence variable entries 
constructed by phase 10 is illustrated in 
Figure 32, 

Indicator Field; The indicator field is 
nonzero if the equivalence variable is sub- 
scripted prior to being dimensioned, 

PI Field; The PI field contains a pointer 
to the dictionary entry for this equiva- 
lence variable. 



Number of Subscripts Field ; The number of 
subscripts field contains the total number 
of subscripts used by a variable being 
equivalenced, with subscripts, prior to 
being dimensioned. 



< 

r 

j Indicator 
J field 



■4 bytes — 
PI field 



Number of | 
subscripts! 



Chain field 



Offset field 
Subscript field 



Subscript field 



Figure 32, Format of Equivalence Variable 
Entry 



Chain_Field; The chain field is used to 
maintain linkage between the various 
variables in the equivalence group. It 
contains a pointer to the equivalence vari- 
able entry for the next variable in the 
equivalence group. 



Of f set Field ; The offset field contains 
the displacement of this variable from the 
first element in the equivalence group. 



Subscript Field ; The subscript field (s) 
contains the actual subscript Cs) specified 
for a variable being equivalenced, with 
subscripts, prior to being dimensioned. 



MODIFICATIONS TO EQUIVALENCE VARIABLE 



ENTRIES ; During 
fields of equival 
be modified. Fig 
format of an equi 
after equivalence 
lEKGST subroutine 
cated; * stands f 



compilation, certain 
ence variable entries may 
ure 33 illustrates the 
valence variable entry 
processing by the STALL- 
Only changes are indi- 
or unchanged. 
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■ 4 bytes- 



r — 

I* 
J.- 



1" 



I* I* 

j. X ^ 

I Displacement of variable from group head ] 



H 



Literal Constant Field ; The literal con- 
stant field contains the actual literal 
constant for which the entry was con- 
structed. The field ranges from 1 to 255 
bytes (1 character/byte, left- justified) 
depending on the size of the literal 
constant. 



• Figure 33. Format of Equivalence Variable 
Entry After Equivalence 
Processing 



MODIFICATIONS TO LITERAL CONSTANT ENTRIES : 
During compilation, certain fields of lit- 
eral constant entries may be modified. 
Figure 35 illustrates the format of a lit- 
eral constant entry after literal process- 
ing by STALL-IEKGST. Only changes are 
indicated; * stands for unchanged. 



■U bytes- 



Literal Table 



The literal table contains literal con- 
stant entries, which describe literal con- 
stants used as arguments in CALL state- 
ments, and literal data entries, which 
describe the literal data appearing in DATA 
statements. (Entries for literal data 
appearing in DATA statements are not 
chained. They are pointed to from data 
text. ) 



LITERAL CONSTANT ENTRY FORMAT ; The format 
of the literal; constant entries constructed 
by phase 10 is illustrated in Figure 34, 



• 4 bytes- 



Chain field 



j Length |Used by STALL-IEKGST 

I field I 

j. j.__^ 

I Literal constant field 
I (variable length) 

L , 

Figure 34. Format of Literal Constant 
Entry 



J Displacement from 
I associated address 
constant 



J* 



•Figure 35. Format of Literal Constant 

Entry After Literal Processing 



LITERAL_DATA_ENTRy_FgRMAT; The format of 
the literal data entries constructed by 
phase 10 is illustrated in Figure 36. 



r 1 

I Length field (1 byte) | 
|. -I 

I Literal data field (1-255 bytes) | 

L J 

Figure 36. Format of Literal Data Entry 



Length Field ; The length field contains 
the length (in bytes) of the literal data 
for which the entry was constructed. 

Literal Data Field; The literal data field 
contains the actual literal data. The 
field ranges from 1 to 255 bytes (1 
character/byte, left- justified) depending 
on the size of the literal data. 



Chain Field; The chain field is used to 
maintain linkage between the various liter- 
al constant entries. It contains a pointer 
to the previous literal constant entry. 

Length Field; The length field contains 
the length (in bytes) of the literal 
constant. 



I Branch Tables 



The branch tables contain initial branch 
table entries and standard branch table 
entries. An initial branch table entry is 
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constructed by phase 10 as it encoianters 
each computed GO TO statement of the source 
module. Standard branch table entries are 
constructed by phase 10 for each statement 
number appearing in the computed GO TO 
statement. 



INITIAL BRANCH TABLE ENTRY FORMAT ; The 
format of the initial branch table entries 
constructed by phase 10 is illustrated in 
Figure 37. 



■U bytes- 



I* 



j Relative address of statement associated 

I with fall-through statement number 

j. 



J Pointer to address constant reserved for 
1 fall-through statement number 

L 

Figure 38. Format of Initial Branch Table 
Entry After Phase 25 
Processing 



■ 4 bytes- 



<— 

r T 

I Indicator | Chain field 
Kield I 

|._„ X 



PI field 



I— - 



1- 



Used by phase 25 



Used by phase 25 

L : J 

Figure 37, Format of Initial Branch Table 
Entry 



STANDARD BRANCH TABLE ENTRY FORMAT : The 
format of the standard branch table entries 
constructed by phase 10 is the same as the 
format for initial branch table entries. 



Indicator _Field; This field is zero for 
standard branch table entries. 



J^IL^J:^^!^ Q^ ^igl<^ • The indicator field is 
nonzero for an initial branch table entry. 
This indicates that the entry is for 
compiler-generated statement number for the 
"fall-through" statement. (The fall- 
through statement is executed if the value 
I of the control variable is equal to zero or 
larger than the number of statement numbers 
in the computed GO TO statement. ) 



Chain_Field: This field is used to main- 
tain linkage between the various branch 
table entries. It contains a pointer to 
the next branch table entry. 



PI Field ; The Pi field contains a pointer 
to the statement number/array table entxy 
for the statement number (appearing in a 
computed GO TO statement) for which the 
standard branch table entry was 
constructed. 



Chain Field ; The chain field is used to 
maintain linkage between the various branch 
table entries. It contains a pointer to 
the next branch table entry. 



MODIFICATIONS TO STANDARD BRANCH TABLE 
ENTRIES: During compilation, certain 
fields of standard branch table entries may 
be modified. Figure 39 illustrates the 
format of a standard branch table entry 
after the processing of phase 25 is com- 
plete. Only changes are indicated; ♦ 
stands for unchanged. 



PI Field; The PI field contains a pointer 
to the statement number/array table entry 
for the compiler-generated statement number 
for the fall-through statement. 



MODIFICATIONS TO INITIAL BRANCH TABLE 
ENTRIES ; During compilation, certain 
fields of initial branch table entries may 
be modified. Figure 38 illustrates the 
format of an initial branch table entry 
after phase 25 processing is complete. 
Only changes are indicated; ♦ stands for 
unchanged. 



r— 

I* 



■U bytes- 



^ ^ 

j Relative address of statement associated | 
jwith this statement number j 

L . J 

Figure 39. Format of Standard Branch Table 
Entry After Phase 25 
Processing 
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FUNCTION TABLE 



The function table (lEKLFT) contains 
entries for the IBM supplied function sub- 
programs and in-line routines. The subpro- 
grams reside on the FORTRAN system li- 
brary (SYSl. FORTLIB) , while the in-line 
routines are expanded at compile time. The 
function table is used by phase 15 to 
determine the validity of the arguments to 
the function subprogram. 



Each entry in the function table (see 
Table 22) contains two fields: an index 
field (2 bytes) and a function n3me field 
( 6 bytes ) . 



FUNTB2(128) — 



FUNTB3(128) — 



FUNTB4(68) — 



This table contains 128 
1-byte entries which give 
the mode of the arguments 
for all library and in-line 
functions. 



This table contains 60 
1-byte entries which give 
the mode of the result for 
all in-line functions. The 
first 68 bytes of the table 
are not used. 



This table contains 68 
U-byte locations reserved 
for dictionary pointers to 
library routines. 



Function Name Field ; Thi^ field contains 
the names of all library and in-line func- 
tions. It is searched in ascending order 
beginning with field 1 and then with field 
2, Field 1 contains the four low-order 
characters of the name; field two contains 
the two high-order characters of the name. 



Table 22. Function Table — lEKLFT 
(12, 128) 




Index Field ; This field contains a pointer 
to entries in the following tables: 



FUNTB1(128) — This table contains 128 

1-byte entries pointing back 
to the function table. 



TEXT OPTIMIZATION BIT TABLES 



There are nine major bit tables used 
extensively throughout text optimization. 
These tables (each four words or 128 bits 
in length) contain bits that are preset. 
Only the first 8 6 bit positions in each 
table are meaningful and each of these is 
associated with a particular text entry 
operator. The settings (on or off) given 
to these bits indicate either the validity 
of operand positions in a text entry with a 
particular operator or the candidacy of a 
text entry with a particular operator for 
text optimization procedures. 



Three of these tables, MVW, MVU, and MW 
are tested by subroutine KORAN-IEKQKO and 
indicate the validity of the operand posi- 
tions in a text entry with a given opera- 
tor. The MVW table indicates the validity 
of the operand 1 position; the MVU table 
indicates the validity of the operand 2 
position; and the MVV table indicates the 
validity of the operand 3 position. For 
example, if the bit in MVW that corresponds 
to a particular operator is set to on, then 
the operand 1 position of a text entry hav- 
ing that operator contains a valid or actu- 
al operand. If the bit is set to off, the 
operand 1 position of the text entry does 
not contain an actual operand. (In the 
latter case, the operand 1 position may 
still contain information that is pertinent 
to the text entry; however, it does not 
contain an actual operand. ) 
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The remaining six tables, MBM, MSGM, 
MGM, MXM, MSM, and MBR are also tested by 
subroutine KORAN- lEKQKO and indicate the 
candidacy of a text entry with a particular 
operator for text optimization procedures. 
The MBM table indicates whether or not text 
entries with a particular operator are to 
be considered for backward movement; the 
MXM table indicates whether or not text 
entries with a particular operator are to 
be considered for common expression elimi- 
nation; the MSM table indicates whether or 
not text entries with a particular operator 
are to be considered for strength reduc- 



tion; and the MBR table indicates whether 
or not the operator is a branch. 



The text optimization bit tables are 
illustrated in Table 23, In this table, 
the operator associated with each bit posi- 
tion in the bit tables is identified. The 
bits settings for each operator as they 
appear in the bit tables is also shown. An 
X signifies that the bit is on; a blank 
signifies that the bit is off. 
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• Table 23, Text Optimization Bit Tables 



Bit 


Operator 


Bit Tables 


Bit 


Operator 


Bit Tables 


MVW 


MVU 


MVV 


MSGM 


MBM 


MXM 


MSM 


MBR 


MGM 


MVW 


MVU 


MVV 


MSGM 


MBM 


MXM 


MSM 


MBR 


MGM 


1 


•NOT- 


X 


X 






X 


X 








44 


LIBF 


X 








X 


X 








2 


UNARY MINUS 


X 


X 






X 


X 








45 


RS 


X 


X 




X 


X 


X 






X 


3 






















46 


LS 


X 


X 




X 


X 


X 






X 


4 


•AND' 


X 


X 


X 




X 


X 








47 


BXHLE 




















5 


) 




















48 






















6 


•OR. 


X 


X 


X 




X 


X 








. 49 






















7 


•XOR' 


X 


X 


X 


X 


X 


X 








50 


•LE^ 


X 


X 


X 




X 


X 








8 


ST 


X 


X 






X 










51 


• GE^ 


X 


X 


X 




X 


X 








9 


, (ARG) 


X 


X 


X 










X 




52 


•EQ^ 


X 


X 


X 




X 


X 








10 


+ 


X 


X 


X 


X 


X 


X 


X 




X 


53 


•LT^ 


X 


X 


X 




X 


X 








11 




X 


X 


X 


X 


X 


X 


X 




X 


54 


•GT^ 


X 


X 


X 




X 


X 








12 


* 


X 


X 


X 


X 


X 


X 






X 


55 


•NE. 


X 


X 


X 




X 


X 








13 


/ 


X 


X 


X 


X 


X 


X 






X 


56 


MAX2 


X 


. X 


X 




X 


X 








14 


LA 


X 


X 


X 




X 










57 


MIN2 


X 


'x 


X 




X 


X 








15 


EXT 


X 


















58 


DIM 


X 


X 


X 




X 


X 








16 


BG 




X 


X 


X 






X 


X 




59 


IDIM 


X 


X 


X 




X 


X 








17 


BL 




X 


X 


X 






X 


X 




60 


DMOD 


X 


X 


X 




X 


X 








18 


BNE 




X 


X 










X 




61 


MOD 


X 


X 


X 




X 


X 








19 


BGE 




X 


X 


X 






X 


X 




62 


AMOD 


X 


X 


X 




X 


X 








20 


BLE 




X 


X 


X 






X 


X 




63 


DSIGN 


X 


X 


X 




X 


X 








21 


BE 




X 


X 










X 




64 


SIGN 


X 


X 


X 




X 


X 








22 


SC 


X 


X 


X 


X 


X 


X 






X 


65 


ISIGN 


X 


X 


X 




X 


X 








23 


I/O LIST 


X 


X 












X 




66 


DABS 


X 


X 






X 


X 








24 


BCOMP 






X 










X 




67 


ABS 


X 


X 






X 


X 








25 


( 




















68 


lABS 


X 


X 






X 


X 








26 


EM 




















69 


ID! NT 


X 


X 






X 


X 








27 


B 




















70 






















28 


BA 




X 












X 




71 


INT 


X 


X 






X 


X 








29 


BBT 




X 


X 










X 




72 


HFIX 


X 


X 






X 


X 








30 


BBF 




X 


X 










X 




73 


IFIX 


X 


X 






X 


X 








31 


LBIT 


X 


X 






X 


X 




X 




74 


DFLT 


X 


X 






X 


X 








32 


BGZ 




X 












X 




75 


FLT 


X 


X 






X 


X 








33 


BLZ 




X 












X 




76 


DBLE 


X 


X 






X 


X 








34 


BNEZ 




X 












X 




77 


BITON 


X 


X 
















35 


BGEZ 




X 












X 




78 


BITOFF 


X 


X 
















36 


BLEZ 




X 












X 




79 


BITFLP 


X 


X 
















37 


BEZ 




X 












X 




80 


ANDF 


X 


X 


X 




X 


X 








38 






















81 


ORF 


X 


X 


X 




X 


X 








39 


NMLST 


X 


X 
















82 


COMPL 


X 


X 






X 


X 








40 






















83 


MOD24 


X 


X 






X 


X 








41 


BF 




X 












X 




84 


LCOMPL 


X 


X 






X 


X 








42 


BT 




X 












X 




85 


SHFTR 


X 


X 


X 




X 


X 








43 


LDB 


X 




X 




X 










86 


SHFTL 


X 


X 


X 




X 


X 
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REGISTER ASSIGNMENT TABLES 



The register assignment tables are a set 
of one- dimensional arrays used by the full 
register assignment routines of phase 20. 
There are three types of tables: local 
assignment tables (see Table 24), global 
assignment tables (see Table 26), and 
register usage tables. The register usage 
tables are work tables used by the local 
and global assignment routines in the proc- 
ess of full register assignment. 



Register Use Table 



The format of the register use tables, 
TRUSE and RUSE, are the same for the local 
and global assignment routines. Each table 
is 16 words long. Words 1 through 11 
represent general registers 1 through 11, 
words 12, li», and 16 represent floating- 
point registers 2, U, and 6, and words 13 
and 15 are unused. 



Table 24. Local Assignment Tables 
Function 



r T' 

1 Name 1 



h 



T 1 

I Origin^ | 



TXP 



BVP 



BVRA 



BVA 



WJ2 



Serves as index to TXPy 
BVRA, BVA. 



BVP, 



Gives the storage location 
of the text item associated 
with each value of J. 

Contains the MCOORD value 
associated with operand 1 of 
the text item represented by 
J. 

Indicates the register 
locally assigned to the 
quantity represented by J. 

Represents the activity 
within the block of the 
quantity represented by J; 
also contains indicator bits 
describing the quantity (see 
Table 25). 

Indicates whether a variable 
is eligible for local 
assignment. Indexed via the 
MCOORD values obtained from 
BVP. 



FWDPAS- 
lEKRFP 

FWDPAS- 
lEKRFP 



FWDPAS- 
lEKRFP 



BKPAS- 
lEKRBP 



FWDPAS- 
lEKRFP 



FWDPAS- 
lEKRFP 



^This column indicates the name of the 
register assignment routine that ini- 
tially creates the particular table. 

^Although WJ is distinctly a local 
assignment table, it is indexed by the 
quantity MCOORD (which is used to index 
the global assignment tables) rather 
than by the local assignment table 
index, J. 
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Table 25. BVA Table 

r T 1 

] Bit I Meaning \ 

|. 1 ^ 

I Not used, 

1 I Text item is candidate for forward 
[movernent. 

2 I Not used. 

3 I Inhibit * inter- block' register 
assignment for text item. 

4 I Text item is candidate for 'inter- 
block' register assignment. 

5 I Text item is candidate for floating- 
point downgrading if a CALL statement' 
is found* 

Text item is candidate for register 
classification. 

PI is the result of an integer mod 
function. 

I The operand has been encountered 
before. 

Text item is the imaginary result of 
a complex function. 

The operand is defined by a function 
call. 

PI is floating point. 

PI is the result of an integer mul- 
tiply or divide. 

Zero length temporary indicator. 

Case II subscript indicator is 
changed to a Case II. 



10 

11 
12 

13 

m 

15 

31 
, X ^ 

I The BVA table consists of a fullword for 
each text in the block, 

L . J 



BVA - Local Activity. 



Table 26, Global Assignment Tables 
Function 



r T- 

] Name | 



t 

I MCOORD 



MVD 



lEMIN 



IRA 



IRAL 



JWA 



jWABP 
] 



Serves as an index to 

MVD, EMIN, RA, RAL, WABP, 
WA and WJ. 



T 1 

I Origin | 

+ ^ 

Phase 15 



Gives the location of the 
dictionary entry for the 
variable associated with 
the given value of 

MCOORD. 



Indicates whether the 
variable associated with 
a particular MCOORD value 
is eligible for global 
assignment. 



Indicates the number of 
the first register glob- 
ally assigned to the 
variable represented by 
the MCOORD value; pro- 
vides continuity in glob- 
al assignment from inner 
to outer loops. 



Indicates the register 
globally assigned to the 
variable represented by 
the MCOORD value. 



Indicates the total 
activity for the variable 
represented by the MCOORD 
value. Calculated by 
adding 4. to the value 
each time a definition of 
the variable is encoun- 
tered and adding 3. to 
the value for a use of 
the variable. 



Indicates the activity of 
base variables. Calcu- 
lated in the same manner 
as the WA table. 



Phase 15 



REGAS- 
lEKRRG 



GLOBAS- 
lEKRGB 



GLOBAS- 
lEKRGB 



FWDPAS- 
lEKRFP 



FWDPAS- 
lEKRFP 



If the contents of TRUSE(i) and RUSE(i) 
is equal to zero, then register i is avail- 
able for assignment. If the value con- 
tained in TRUSE(i) or RUSE(i) is between 2 
and 128, inclusive, then the register i is 
assigned to the variable whose MCOORD value 
is equal to the contents of TRUSE(i) or 
RUSE(i). If the contents of TRUSE(i) or 
RUSE(i) has a value between 252 and 255, 
register i is unavailable for assignment 



and is reserved for special use (see next 
paragraph) . 



Register Use Considerations ; Registers 15 
and lU are not available for use by 
register assignment. They are reserved, 
and used for branching during the execution 
of the object module resulting from the 
compilation. 
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Register 13 is not available for use by 
register assignment. It is reserved, and 
used during the execution of the object 
module to contain the address of the save 
area set aside for the object module (refer 
to Fortran System Director, "Generation of 
Initialization Instructions"). Register 13 
is also used to refer to: 

• Branch tables for computed GO TO 
statements . 

• Parameter list for external references. 

• Local constants, variables and arrays. 

• Adcons for external references. 

If the above items exceed 409 6 bytes, 
the adcons are referred to by register 12. 

Register 12 is not available for use by 
register assignment. It is set aside to 
contain the starting address of the "Con- 
stants" portion of text information. 

Registers 11, 10, and 9 may or may not 
be available for use by register assign- 
ment. Their use depends upon the number of 
required reserved registers (see Phase 20, 
"Branching Optimization"). 



r 1 

I Name field (2 words) | 
^ ^ 

1 Address field (1 word) | 
^ ^ ^ ^ 

I Item Type | Mode | Not used | 
] field I field | (2 bytes) | 
I (1 byte) I (1 byte) | j 

L J. X J 

Figure 41. Format of Naraelist Variable 
Entry 



Name Field; The name field contains the 

name of the variable, right- justified, with 
leading blanks. 



Address Field ; The address field contains 
the relative address of the variable. 

iS:§S!;_3!YE§_Ei®l^' This field is zero for a 
variable. 



Mode Field: 



The mode field contains the 



mode of the variable. 



NAMELIST DICTIONARIES 



NAMELIST ARRAY ENTRY FORMAT; 



The format of 



the entry constructed for an array appear- 
ing in a NAMELIST statement is illustrated 
in Figure 42. 



Namelist dictionaries are developed by 
CORAL for the NAMELIST Statements appearing 
in the source module. These dictionaries 
provide IHCNAMEL with the information 
required to implement READ/WRITE statements 
using NT^ELISTs. The namelist dictionary 
constructed by CORAL from the phase 10 
namelist text representation of each NAME- 
LIST statement contains an entry for the 
namelist name and entries for the variables 
and arrays associated with that name. 

NAMELIST NAME ENTRY FORMAT ; The format of 
the entry constructed for the namelist name 
is illustrated in Figure 40. 



I Name field 

L 



(2 words) 1 
J 



Figure 40. Format of Namelist Name Entry 



^aill^_5!i§i^ • The name field contains the 
namelist name, right- justified, with lead- 
ing blanks. 

NAMELIST_VARIABLE_ENTRy_FORMAT: The format 
of the entry constructed for a variable 
appearing in a NAMELIST statement is illus- 
trated in Figure 41. 



Name field 



(2 words) 



Address field 



(1 word) 



Item Type 
field 

(1 byte) 



Indicator 
field 
(1 byte) 



Not used 
(1 byte) 



Not used 
(1 byte) 



~T T 

Mode I Number of | Element 
field I dimensions I length 

I field I field 
(1 byte) I (1 byte) | (1 byte) 
L JL 



First dimension 
factor field 
(3 bytes) 



Second dimension 
factor field 
(3 bytes) 



Third dimension 
factor field 
(3 bytes) 



1 Etc. (refer to "Dimension Entry Format") | 

L . J 

Figure 42. Format of Namelist Array Entry 



Name Field; The name field contains the 
name of the array, right- justified, with 
leading blanks. 
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Address Field: The address field contains 
the relative address of the beginning of 
the array. 



Item Type Field : 
an array. 



This field is nonzero for 



DIAGNOSTIC MESSAGE TABLES 



There are two major diagnostic tables 
associated with error message processing by 
phase 30: the error table and the message 
pointer table. 



Mode Field ; This field contains the mode 
of the elements of the array. 



ERROR TABLE 



Number of Dimensions_Field; This field 
contains the number of dimensions (1 
through 7) of the associated array. 

Element Length Field ; The element length 
field contains the length of each element 
in the associated array. 

I ndica tor Field ; This field is zero if the 
associated array has variable dimensions; 
otherwise, it is nonzero. 

First Dimension Factor Field ; If the asso- 
ciated array does not have variable dimen- 
sions, this field contains the total size 
of the array. If the array has variable 
dimensions, this field contains the rela- 
tive address of first subscript parameter 
used to dimension the array. 

SecondPimension Factor Field ; If the 
associated array does not have variable 
dimensions, this field contains the loca- 
tion of the second dimension factor (Dl*L) . 
If the array has variable dimensions, this 
field contains the relative address of the 
second subscript parameter used to dimen- 
sion the array. 

Third D,i.n'eiision_Factor_Field; If the asso- 
ciated~array does not have variable dimen- 
sions, this field contains the location of 
the third dimension factor (D1*D2*L) . If 
the array has variable dimensions, this 
field contains the relative address of the 
third subscript parameter used to dimension 
the array. 



The error table is constructed by phases 
10 and 15. As source statement errors are 
encountered by these phases, corresponding 
entries are made in the error table. Each 
error table entry consists of 2 one-word 
fields. The first field contains either an 
internal statement number, if the entry is 
for a statement that is in error, a dic- 
tionary pointer, if the entry is for a sym- 
bol that is in error (e.g., a variable that 
is incorrectly used in an EQUIVALENCE 
statement) , or a statement number, if the 
entry is for an undefined statement number; 
the second field contains the message num- 
ber associated with the particular error. 
The message numbers that can appear in the 
error table are those associated with mes- 
sages of error code levels U and 8 (refer 
to the publication IBM_Sy stem/360 Operating 
System; FORTRAN IV (G and H) Programmer's 
Guide) . 



MESSAGE POINTER TABLE 



The message pointer table contains an 
entry for each message number that may 
appear in an error table entry. Each entry 
in the message pointer table consists of a 
single word. The high-order byte of the 
word contains the length of the message 
associated with the message number. The 
three low-order bytes contain a pointer to 
the text for the message associated with 
the message number. 
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APPENDIX B: INTERMEDIATE TEXT 



Intermediate text is an internal repre- 
sentation of the source module from which 
the machine instructions of the object 
module are generated. The conversion from 
intermediate text to machine instructions 
requires information about variables, con- 
stants, arrays, statement numbers, in-line 
functions, and subscripts. This informa- 
tion, derived from the source statements, 
is contained in the information table, and 
is referred to by the intermediate text. 
The information table supplements the 
intermediate text in the generation of 
machine instructions by phase 25. 



PHASE 10 INTERMEDIATE TEXT 



Phase 10 creates intermediate text (in 
operator-operand pair format) for use as 
input to subsequent phases of the compiler. 
There are six types of intermediate text 
produced by phase 10: 

• Normal text — the operator-operand 
pair representations of source state- 
ments other than DATA, NAMELIST, DEFINE 
FILE, FORMAT, and Statement Functions 
(SF). 

• Data text — the operator - operand 
pair representations of DATA statements 
and the initialization constants in 
explicit type statements. 

• Namelist text — the operator-operand 
pair representations of NAMELIST 
statements. 

• Define file text — the operator- 
operand pair representation of DEFINE 
FILE statements. 

• Format text — the internal representa- 
tions of FORMAT statements. 

• SF skeleton text — the operator- 
operand pair representations of state- 
ment functions using sequence numbers 
as operands of the intermediate text 
entries. The sequence numbers replace 
the dummy arguments of the statement 
functions. This type of text is, in 
effect, a "skeleton" macro. 

Note ; Intermediate text representations 
are, for subblock allocation, divided into 
only two main types: special (DATA, NAME- 
LIST, DEFINE FILE, FORMAT, and SF skeleton 
text), and normal (text other than special 



text). The intermediate text representa- 
tions are comprised of individual text 
entries. Each intermediate main text type 
is allocated unique subblocks of main 
storage. The subblocks that constitute an 
intermediate text area are obtained by 
phase 10, as needed, via requests to the 
FSD (see "Storage Distribution" under "FOR- 
TRAN System Director"). 



Intermediate Text Chains 



Each intermediate text area (i. e. , the 
subblocks allocated to a particular type of 
text) is arranged as a chain that links 
together (1) the text entries that are 
developed and placed into that area, and 
(2) in some cases, the intermediate text 
representation for individual statements. 

The normal text _c hain is a linear chain 
of normal text entries; that is, each 
normal text entry is pointed to by the pre- 
viously developed normal text entry. 



The data text __ chain in bi- linear, 
means that: 



This 



1. The text entries that constitute the 
intermediate text representation of a 
DATA statement are linked by means of 
pointers. Each text entry for the 
statement is pointed to by the pre- 
viously developed text entry for the 
statement. 

2. The intermediate text representations 
of individual DATA statements are 
linked by means of pointers, each 
representation being pointed to by the 
previously developed representation. 
(A special chain address field within 
the first text entry developed for 
each DATA statement is reserved for 
this purpose. ) 

The namelisttext chain operates in the 
same manner as the data text chain. 

The define file text ch ain is a linear 
chain of define file text entries, each 
define file text entry is pointed to by a 
previously developed define file text 
entry. A zero chain signals the end of all 
define file text for a program. 

The format text _cha in consists of link- 
ages between the individual intermediate 
text representations of FORMAT statements. 
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The pointer field of the second text entry 
in the intermediate representation of a 
FORMAT statement points to the intermediate 
text representation of the next FORMAT 
statement. (The individual text entries 
that make up the intermediate text repre- 
sentation of a FORMAT statement are not 
chained. ) 

The SF sk eleton text chain is linear 
only in that each text entry developed for 
an operator-operand pair within a particu- 
lar statement function is pointed to by the 
previous text entry developed for that same 
statement function. The intermediate text 
representations for separate statement 
functions are not chained together. Howev- 
er, a skeleton can readily be obtained by 
means of the pointer contained in the dic- 
tionary entry for the name of the statement 
function. 



Mode and Type Fields ; The mode and type 
fields contain the mode and type of the 
operand of the text entry. Both items 
appear as numeric quantities in a text 
entry and are obtained from the mode and 
type table (see Tables 20 and 21). 



Pointer Field ; The pointer field contains 
a pointer to the information table entry 
for the operand of the operator-operand 
pair. Howeveri if the operand is a dummy 
argument of a statement function, the 
pointer field contains a sequence number, 
which indicates the relative position of 
the argument in the argument list. 

Note; The text entries for FORMAT state- 
ments are not formatted as described in the 
foregoing. FORMAT text entries consist of 
the characters of the FORMAT statement in 
source format packed into successive text 
entries. 



Format_of_Intermediate_Text_Entry 



Those statements that undergo conversion 
from source representation to intermediate 
text representation are divided into 
operator-operand pairs, or text entries. 
Figure 43 illustrates the format of an 
intermediate text entry constructed by 
phase 10. 



<- 



■ 4 bytes- 



r T- 

1 Adjective ] 

j code field) Chain field 

I (operator) | 

J- 



JMode field 
|. 



J Type field 
-i 



I Pointer field (operand) \ 

L X- . J 

Figure 43. Intermediate Text Entry Format 



Adject ive_Code_Fi eld ; The adjective code 
field corresponds to the operator of the 
operator-operand pair. Operators eire not 
entered into text entries in source form; 
they are converted to a numeric value as 
specified in the adjective code table (see 
Table 27). it is the numeric representa- 
tion of the source operator that actually 
is inserted into the text entry. Primary 
adjective codes (operators that define the 
nature of source statements) also have nu- 
meric values. 

Chain Field; The chain field is used to 
maintain linkage between intermediate text 
entries. It contains a pointer to the next 
text entry . 



Table 27. Adjective Codes (Part 1 of 3) 
r T T 1 







Mnemonic 




Code ( 


in 


(where 




decima 


1) 


applicable) 

L , 


Meaning 











1 




.NOT. 


NOT 


4 




.AND. 


AND 


5 




) 


Right arithmetic 
parenthesis 


6 




.OR. 


OR 


7 




.XOR. 


Exclusive OR 


8 




= 


Equal sign 


9 




1 


Comma 


10 




+ 


Plus 


11 




- 


Minus 


12 




* 


Multiply 


13 




/ 


Divide 


14 




♦ * 


Exponentiation 


15 




(f 


Function parenthesis 


16 




.LE. 


Less than or equal 


17 




.GE. 


Greater than or 
equal 


18 




.EQ. 


Equal 


19 




.LT. 


Less than 



L X X J 
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Table 27. Adjective Codes (Part 2 of 3) 
r T T 1 



Table 27. Adjective Codes (Part 3 of 3) 
r T T 1 



1 

1 Code ( in 
j decimal) 
1 


Mnemonic 

(where 

applicable) 


Meaning 




r — i 

1 20 


.GT. 


— 

Greater than 


1 21 


• NE. 


Not equal 


1 22 


(s 


Left subscript 
parenthesis 


1 25 


( 


Left arithmetic 
parenthesis 


1 26 




End mark 


1 71 




GO TO, and implied 
branches 


1 193 




BLOCK DATA 


j 205 




DATA 


1 208 




SUBROUTINE, 
FUNCTION, or ENTRY 


1 209 




FORMAT (text) 


1 210 




End of I/O list 


1 211 




CONTINUE 


1 212 




Relative record 
number 


1 213 
1 




Object time format 
variable 


1 214 




BACKSPACE 


1 215 




REWIND 


1 216 




END FILE 


] 217 




WRITE unformatted 


1 218 




READ unformatted 


1 219 




WRITE formatted 


1 220 




READ formatted 


I 221 




Beginning of I/O 
list 


1 222 
t 


LDF 


Statement number 
definition 



jcode (in 
1 decimal) 
1 


Mnemonic 

(where 

applicable) 


1 

Meaning j 
j 


r 

1 223 




GLDF 


_ -j 

Generated statement | 
number definition | 


1 225 




WRITE using NAMELIST | 


1 226 




READ using NAMELIST | 


j 227 




FIND 1 


1 230 




I/O end-of-file j 
parameter j 


1 231 




I/O error parameter | 


1 232 




BLANK 1 


1 233 


RET 


RETURN 1 


1 234 


STOP 


STOP 1 


1 235 




PAUSE 1 


1 238 




ASSIGN 1 


1 240 




Beginning of DO j 


1 241 




Arithmetic | 
assignment statement | 


1 242 


NDOIF 


End of DO 'IF' 1 


1 243 




Arithmetic IF | 


j 244 




Relational IF | 


1 246 




CALL 1 


1 247 


LIST 


I/O or NAMELIST list| 
item 1 


1 248 




NAMELIST 1 


1 249 


END 


END 1 


] 250 




Computed GO TO | 


1 251 




I/O unit number j 


1 252 




FORMAT (statement | 
numbers) | 


1 253 




NAMELIST name | 
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Examples of Phase 10 Interitiediate Te xt 



An example of each type of phase 10 text 
(normal, data, namelist, define file for- 
mat, and SF skeleton) is presented below. 
For each type, a source language statement 
is first given. This is followed by the 
phase 10 text representation of that 
statement. 



The phase 10 normal_text representation 
of the arithm.etic statement 



100 A=B+C*D/E 



is illustrated in Figure 44. 



T T" 

I I 

Type I I 
+ +- 



j Adjective 
I Code 

I- 

I Statement 

I number 

I definition 



Chain 



Mode 



Pointer 



^ 



I statement 
I number 



100 



Arithmetic 



Real 



j Scalar"" j 



-+- 



Real 



j Scalar"* j j 



4 4 4. 

I Scalar" j |- 



Real 



Real 



I Scalar" | 



u 



Real 



1 Scalar" | 
+ +- 



i: 



End mark^ 



To next normal 
text entry 







ISN- 



jT 



I 1 byte 
I- 



3 bytes 



2 bytes 



I 1 I 
2 bytes | byte | 

X X. 



3 bytes 



I ""Nonsubscripted variable. 

I ^Operator of the special text entry that signals the end of the text representation 

I of a source statement. 

I ^Compiler generated sequence number used to identify each source statement. 

L . 

Figure 44. Phase 10 Normal Text 
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The phase 10 data text representation of 
the DATA statement 



DATA A, B/2. 1, 3HABC/, C, D/1. , 1. / 



is illustrated in Figure 45. 



Adjective 
Code 



Chain 



Mode 



Type 



Pointer 



I— -- 



DATA 



ISN 



To text for 
next DATA 
statement 



H 



Q 



F"-" 



Real 



Scalar | 



+- 

Scalar j 



Q 



F"-" 



Real 



Q 



Real 



I Constant] 
4 4 



2. 1 



Q 



Literal 



I Constant | 



3HABC 



CT 



Real 



Scalar 



■i- 



^ 



Real 



I Scalar | 
I 4-. 



Q 



Real 



I Constant ( 



1. 



■i- 



■i- 



Real 



I Constant | 



1. 



-+■ 



-+- 



1 byte 



3 bytes 



2 bytes 



I 1 

I 2 bytes |byte 
.X X 



3 bytes 



Figure 45. Phase 10 Data Text 
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The phase 10 namelist text representa- 
tion of the NAMELIST statement 



NAMELIST /NAMEl/A, B„ C/NAME2/D, E, F/NAME3/G 



where A and F are arrays is illustrated in 
Figure 46. 



Adjective 
Code 



Chain 



Mode 



Type 



T T' 

I 

I 



+- 



Pointer 



-4- 



Q 



NAMELIST 



NAMELIST 



NAMEl 



+- 



Q 



To text for 
next NAMELIST 
block 



Q 



LIST 



Real 



i Array 



A 



Q 



LIST 



Real 



Scalar 



^ 



LIST 



Real 



Scalar 



Q 



NAMELIST 



NAMELIST 



NAME 2 



Q 



To text for 
next NAMELIST 
block 



|*J 



Q 



LIST 



Real 



Scalar 



•D 



Q 



LIST 



Real 



Scalar 



Q 



LIST 



Real 



irray 



Q 



NAMELIST 



NAMELIST 



NAME 3 



Q 



To text for 
■♦next NAMELIST 
statement 



H 



LIST 



Real 



Scalar 



■+- 



1 byte 



3 bytes 



2 bytes 



I 2 bytes 



L L J.- 

Figure 46, Phase 10 Namelist Text 



byte I 
L. 



3 bytes 
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The phase 10 define file text represen- 
tation of the DEFINE FILE statement 

DEFINE FILE a^. (mi, r^, f i, v^ ) 

where a^ is the input/output unit number, 
mx is the number of records, r^. is the 
maximum record length, fj. is the format 
code, and v^. is the associated variable, is 
illustrated in Figure 47, 



Adjective 
Code 



1-- 



I Chain 



^JOde 



-+- 



I Type 
-+ 



Pointer 



Q 



I I/O unit number I 

(. 4 



Integer 



I Constant | 



Integer 



^ 



I Constant | 
4- 



Q 



-+- 



Integer 



+_ 

oritiat code(fi) | pointer to next | 
I define file text j 
I entry j 



j Constant | 
4- 



Integer 



Scalar 



jT-T- 



4- 



+- 



I 1 byte 

L 



3 bytes 



I I 1 

2 bytes | 2 bytes |byte 

X X 



3 bytes 



Figure 47. Phase 10 Define File Text 



The phase 10 format text representation 
of the FORMAT statement 

5 FORMAT (2H0A, A6//5X, 3 
(m,E12.5, 3F12.3, 'ABC' ) ) 

is illustrated in Figure U8. 



I Pointer 
I Code 



Chain 



Mode 



Type 





4 + 



Pointer 



Statement 

number 

definition 



u 



statement 
number 



FORMAT 



To text for 
next FORMAT 
statement 



n 



I 1 byte 
j. 



3 bytes 



2 bytes 



2 bytes 



byte 



3 bytes 



I- 



(2H0 2 



A,A6 ^ 



//5X 2 



,3 (I 



4, El 2 



2.5, 



3F12 2 



I— - 

I ^Group mark. 

I 20ne character per byte. 



.3,' 



ABC 2 I 



))f 



Figure 48. Phase 10 Format Text 
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The phase 10 SF skeleton text represen- 
tation of the statement function 

ASF (A, B, C) = A+D+B+E/C 

is illustrated in Figure 49. 



Adjective 
Code 



Chain 



Mode 



Type 



Pointer 



^ 



Q 



Real 



Scalar | 
+- 



17 







+- 

Scalar | 
4- 



U 



Real 



Q 







Q 



End mark 







+ +- 

I 1 I 

2 bytes | by te | 

X X, 



1 byte 



3 bytes 



2 bytes 



3 bytes 



Figure 49. Phase 10 SF Skeleton Text 



PHASE 15/PHASE 20 INTERMEDIATE TEXT 
MODIFICATIONS 



During phase 15 and phase 20 text 
processing, the intermediate text entries 
are modified to a format more suitable for 
optimization and object-code generation. 
The intermediate text modifications made by 
each phase are discussed separately in the 
following paragraphs. 



Unchanged Text 



The unchanged text is the phase 10 
normal text that is not changed but rear- 
ranged in format by phase 15 (see figure 
43). Unchanged text is passed on to subse- 
quent phases with these modifications: 



1. The mode and type fields are each 
expanded to a fullword. 



PHASE 15 INTERMEDIATE TEXT MODIFICATIONS 



The intermediate text input to phase 15 
is the intermediate text created by phase 
10. The intermediate text output of phase 
15 is an expanded version of phase 10 
intermediate text. The intermediate text 
output of phase 15 is divided into four 
categories : 



2. A new word is inserted between the 
chain field and the mode field. 



3. The adjective code is moved from the 
first byte of the chain field to the 
third byte of this new word. 



Phase 15 Data Text 



• Unchanged text 

• Phase 15 data text 

• Statement number text 

• Standard text 



To facilitate the assignment of initial 
data values to their associated variables, 
phase 15 converts the phase 10 data text 
for DATA statements to phase 15 data text, 
which is in variable-constant format. The 
format of the phase 15 data text entries is 
illustrated in Figure 50. 
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Indicator Field; The indicator field indi- 
cates the characteristics of the initial 
data value (constant) to be assigned to the 
associated variable. This field is one 
byte in length. The indicator field is 
divided into eight subfields, each of which 
is one bit long. The bits are ntimbered 
from through 7. Figure 51 indicates the 
function of each subfield in the indicator 
field. 



PI Field ; The Pi field contains a pointer 
to the dictionary entry for the variable to 
which the initial data value is to be 
assigned. 



P2 Field ; The P2 field contains a pointer 
to the dictionary entry for the initial 
data value (constant) which is to be 
assigned to the associated variable. 



<- 



Indicator j 
field j 
J.. 



PI field 



P2 field 



Offset field 



Number field 



■4 bytes- 



Chain field 



Figure 50. Format of Phase 15 Data Text 
Entry 



Of f §^£_I!i§ld ; The offset field contains 
the displacement of the subscripted vari- 
able from the first element in the array 
containing that variable. If the variable 
to which the initial data value is to be 
assigned is not subscripted, this field 
does not exist. 



Number Field ; The number field contains an 
indication of the number of successive 
items to which the initial data value is to 
be assigned. If the initial data value is 
not to be assigned to more than one item, 
this field does not exist. 



r "" """ 




-T- 


1 


1 Subfield 




Function | 






1 


_ _ _ _ J 






1 


- - - - i 


1 Bit 




1 


not used | 

_ _ _j 






I 


_ _ _ _ _^ 


1 Bit 1 




{I 


not used | 

_ _ J 






1 


— _ _ _ _ — ^ 


1 Bit 2 




,1 


not used | 
_ _ _ _j 






J 


— _ _ _ — _^ 


j Bit 3 




1 


not used | 

. J 






I 


— — ^ 


1 Bit a 


•on' 


■] 


initial data value is nega- | 

tive constant j 

_ _ _J 






J 


1 


j Bit 5 


'on* 




initial data value is a | 








literal constant ] 






1 


_ _ i 






il 


_ _ ^ 


1 Bit 6 


'on' 


1 


initial data value is in | 

hexadecimal form | 
_ _ _ _ _i 


r 




1 


— - - - - - -1 


I Bit 7 


•on' 




data table entry is six 1 
words long (variable is an j 
array element). | 






-±. 


_ _j 



Figure 51. Function of Each Subfield in 
Indicator Field of Phase 15 
Data Text Entry 



Chain Field; The chain field is used to 
maintain linkage between the various phase 
15 data text entries. It contains a point- 
er to the next such entry. 



Statement Number Text 



The statement number text is an expanded 
version of the phase 10 intermediate text 
created for statement numbers. It is 
expanded to provide additional fields in 
which statistical information about the 
text block associated with the statement 
niimber is stored. The format of statement 
number text entries is illustrated in 
Figure 52, 



' 





U bytes 




Chain field 


Not used 




T 

1 Operator 

1 field 

J. 


T 

1 Indicator 

1 field 
J. 


PI field 


BLKEND field 


Use vector field 


(MVF) 


(4 words) 


Definition vector 


field (MVS) 


(U words) 


Busy-on-exit 
vector field 


(MVX) 


( 4 words ) 



Figure 52, Format of Statement Number Text 
Entry 
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Chain Field;: The chain field is used to 
maintain the linkage between the various 
intermediate text entries. It contains a 
pointer to the next text entry. 



BLKEMD Field ; The BLKEND field contains a 
pointer to the last intermediate text entry 
within the block. 



Operator _ Field ; The operator field con- 
tains an internal operation code (numeric) 
for a statement number definition (see 
Table 28). 



Indicator Field (ABFN) ; The indicator 
field is one byte long. This field indi- 
cates some of the characteristics of the 
text entries in the associated block. The 
indicator field contains eight subfields, 
each of which is one bit long. The sub- 
fields are numbered through 7. Figure 53 
indicates the function of each subfield in 
the indicator field. 



field is used to 
and constants are 
block. Variables 
are encountered i 
STALL- lEKGST are 
ordinate (1 bit) 
general, if the i 
the variable or c 
ith co-ordinate i 
block. 



(MVF) ; The use vector 
indicate which variables 
used in the associated 
and constants, as they 
n the module by subroutine 
assigned a unique co- 
in this vector field. In 
th bit is set to on (1), 
onstant assigned to the 
s used in the associated 



Subfield 1 Function 

. _ _ 1 _ _ _ 


• T - - 

Bits 0-3 ] not used 
„| _ 

Bit 4 'on" ] associated block contains 
1 an input/output operation 
__4 

Bit 5 'on* 1 associated block contains 
1 a reference to a library 
1 function 

_ _ JL _ 


T 

Bit 6 1 not used 
__+ . 

Bit 7 'on' 1 associated block contains 
J an abnormal function 
i reference 



L 



._i . J 



Figure 53. Function of Each Subfield in 
Indicator Field of Statement 
Number Text Entry 



PI Field ; The PI field contains a pointer 
to the statement number/array table entry 
for the statement number. 



Definition_yector Field__(MVS)_; The defini- 
tion vector field is used to indicate which 
variables are defined in a block. 
Variables and constants, as they are 
encountered by subroutine STALL-IEKGST are 
assigned a unique co-ordinate (1 bit) in 
this vector field. In general, if the ith 
bit is set to on (1) , the variable assigned 
to the ith co-ordinate is defined in the 
associated block. 



Busy-On-Exit Vector Field (MVX) ; The busy- 
on-exit vector field in phase 15 indicates 
which variables are not first used and then 
defined within the text block (not busy-on- 
entry). This field is converted by phase 
20 to busy-on-exit data, which identifies 
those operands that are busy-on-exit from 
the block. Variables and constants, as 
they are encountered by subroutine STALL- 
IEKGST are assigned a unique co-ordinate 
(1 bit) in this vector field. In general, 
during phase 15, if the ith bit is set to 
on (1) , the variable assigned to the co- 
ordinate is not busy-on-entry to the block. 
During phase 20, if the ith bit is set to 
on, the variable or constant assigned to 
the ith co-ordinate is busy-on-exit from 
the block. 
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Table 28. Phase 15/20 Operators (Part 1 
of 5) 



r 

jcode (in 
1 decimal) 
I 


r 1 

Mnemonic 

(where 

applicable) 




Meaning 


r 

1 1 


.NOT. 


. 

NOT 


1 2 


U 


Unary minus 


1 ^ 


.AND. 


AND 


1 5 


) 


Right parenthesis 


1 6 


.OR. 


OR 


1 7 


.XOR. 


XOR 


1 

1 B 


ST 


Store 


1 9 


r 


Argument 


1 10 


+ 


Plus 


1 11 


- 


Minus 


1 12 


* 


Multiply 


1 13 


/ 


Divide 


1 14 


LA 


Load address 


1 15 

i 

1 


EXT 


External function or 
subroutine CALL 


1 16 


BG 


Branch greater than 


1 17 


BL 


Branch less than 


1 18 


BNE 


Branch not equal 


1 19 


BGE 


Branch greater than 
or equal 


1 20 


BLE 


Branch less than or 
equal 


1 21 


BE 


Branch equal 


1 22 


SUB 


Subscript 


i 23 


LIST 


I/O list 


1 24 


BC 


Branch computed 


1 25 


( 


Left parenthesis 


1 26 i 


EM 


End mark 


1 27 


B 


Branch 


1 28 


BA 


Branch assigned 


1 29 
1 


BBT 


Branch bit true 


1 

1 30 ] 


BBF 


Branch bit false 



•Table 28. Phase 15/20 Operators (Part 2 
of 5) 

r T r 



H h- 



Code (in 
decimal) 


Mnemonic 

(where 

applicable 


Meaning 


31 




LBIT 




Logical value of bit 


32 


BGZ 


Branch greater than 
zero 


33 


BLZ 


Branch less than 
zero 


34 


BNEZ 


Branch not equal to 
zero 


35 


BGEZ 


Branch greater than 
or equal to zero 


36 


BLEZ 


Branch less than or 
equal to zero 


37 


BEZ 


Branch equal to zero 


39 


NMLS 


NAMELIST operands 


41 


BF 


Branch false 


42 


BT 


Branch true 


43 


LDB 


Load byte 


44 


LIBF 


Library function 
call 


45 


RS 


Right shift 


46 


LS 


Left shift 


47 


BXHLE 


Branch on index 


48 


ASSIGN 


Assign 


50 


LE 


Less than or equal 


51 


GE 


Greater than or 
equal 


52 


EQ 


Equal 


53 


LT 


Less than 


54 


GT 


Greater than 


55 


NE 


Not equal 


56 


MAX2 


MAX2 in-line routine 


57 


MIN2 


MIN2 in-line routine 


58 


DIM 


DIM in-line routine 


59 


I DIM 


IDIM in-line routine 


60 


DMOD 


DMOD in-line routine 



L X X J 



L X X J 
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Table 28. Phase 15/20 Operators (Part 3 
of 5) 

r T ■ T 1 



• Table 28. Phase 15/20 Operators (Part 4 
of 5) 



Code (in 
decimal) 


Mnemonic 

(where 

applicable) 


Meaning 

., 


61 


MOD 


MOD in-line routine 


62 


AMOD 


AMOD in-line routine 


63 


DSIGN 


DSIGN in-line 
routine 


64 


SIGN 


SIGN in-line routine 


65 


ISIGN 


ISIGN in-line 
routine 


66 


DABS 


DABS in-line routine 


67 


ABS 


ABS in-line routine 


68 


lABS 


lABS in-line routine 


69 


IDINT 


IDINT in-line 
routine 


71 


INT 


INT in-line routine 


72 


HFIX 


HFIX in-line routine 


73 


IFIX 


IFIX in-line routine 


74 


DFLOAT 


DFLOAT in-line 
routine 


75 


FLOAT 


FLOAT in-line 
routine 


76 


DELE 


DBLE in-line routine 


77 


BITON 


BITOM in-line 
routine 


78 


BITOFF 


BITOFF in-line 
routine 


79 


BITFLP 


BITFLP in-line 
routine 


80 


ANDF 


ANDF in-line routine 


81 


ORF 


ORF in-line routine 


82 


COM PL 


COMPL in-line 
routine 


83 


MOD24 


MOD 2 4 in-line 
routine 


84 


LCOMPL 


LCOMPL in-line 
routine 



r 1 

jcode (in 
J decimal) 

1 _ J 


r ■ 

Mnemonic 

(where 

applicable 

L _ _ 


-T 

) 1 Meaning 
J. _ 


r 1 
1 85 


SHFTR 


T 

1 SHFTR in-line 
1 routine 


1 86 


SHFTL 


1 SHFTL in-line 
1 routine 


1 100 


LR 


I Load register (phase 
|20 only) 


} 101 


RC 


[Restore main storage 
1 (phase 20 only) 


1 102 


RR 


[Restore register 
1 (phase 20 only) 


1 103 




1 Register usage 
1 (phase 20 only) 


1 104 




1 STORE (phase 20 
[only) R13 as 
1 operand 2 


1 203 




[Register usage 
1 (phase 20 only) 


1 208 




[FUNCTION or 
[SUBROUTINE 


1 210 




1 END input/output 


1 211 




1 CONTINUE 


1 212 




[Relative record 
1 number 


] 213 




[Object time FORMAT 


1 214 




1 BACKSPACE 


1 215 




[REWIND 


1 216 




[END FILE 


] 217 




(WRITE unformatted 



L J. X J 



L ± L J 
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Table 28. Phase 15/20 Operator (Part 5 of 
5) 



Code (in 
decimal) 

218 


r 

Mnemonic 

(where 

applicable) 


J. _ _ _ _ — ^ 

1 Meaning j 
J. ^ 

|READ unformatted | 


219 




1 WRITE formatted | 


220 




|READ formatted | 


221 




1 Begin input/output j 


222 


LDF 


1 Statement niimber | 
j definition j 


223 


GLDF 


1 Generated statement ] 
I number definition ] 


225 




1 WRITE using NAMELIST] 


226 




|READ using NAMELIST ] 


227 




1 FIND 1 


230 




Input/output end-of-| 
file parameter 1 


231 




Input/output error j 
parameter j 


232 




1 BLANK 1 


233 


RET 


i RETURN 1 


23U 


STOP 


STOP 1 


235 




PAUSE ] 


249 


END 


END 1 


251 




Input/output unit | 
number j 


252 




FORMAT statement ] 
number j 


253 




NAMELIST 1 



S tandard Text 

The standard text is an expanded and 
modified form of phase 10 intermediate text 
that is more suitable for optimization. 
The format of standard text entries is 
illustrated in Figure 5U. 



U bytes- 
Chain field 



Set by phase 20 
Used by phase 25 



T T 

1 Operator |Mode 
Ifield Ifield 

.± X 



I Set by phase 20 | 

jUsed by phase 25|P1 field 



I Set by phase 20 j 

jUsed by phase 25|P2 field. 



h 



-4- 



jSet by phase 20 

I Used by phase 25|P3 field 

^ _ ± 

I Displacement field j 

L J 

Figure 54. Format of a Standard Text Entry 



Chain Field; 



The chain field is used to 



maintain the linkage between the various 
intermediate text entries. It contains a 
pointer to the next text entry. 

Operator Field : The operator field con- 
tains an internal operation code (numeric) 
that indicates either the nature of the 
statement or the operation to be performed 
(see Table 28 ). 

Pl_Field: The PI field contains either a 
pointer to the dictionary entry or state- 
ment number/array table entry for operand 1 
of the text entry < or zero (0) if operand 1 
does not exist. 

P2 Field : The P2 field contains either a 
pointer to the dictionary entry for operand 
2 of the text entry or zero (0) if operand 

2 does not exist. 

P3_Field: The P3 field contains either a 
pointer to the dictionary entry for operand 

3 of the text entry, a pointer to a parame- 
ter list in the adcon table, an actual con- 
stant (for shifting operations), or zero 
(0) if operand 3 does not exist. 

Mode _Fi eld; The mode field indicates the 
general mode of the expression and the mode 
of the operands. The bits are set by phase 
15. The mode field can be referred to only 
as the fourth byte of the status mode word, 
which consists of a status field (2 bytes), 
an operator field (1 byte) , and the mode 
field (1 byte). The status portion of the 
status mode word is explained later under 
"Phase 20 Intermediate Text Modification. " 
The meanings of the bits in the mode field 
are given in Table 29. 

Displacement Field ; The displacement field 
appears only for subscript and load address 
text entries; it contains a constant dis- 
placement (if any) computed from constants 
in the subscript expression. 
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• Table 29. Meanings of Bits in Mode Field of Standard Text Entry Status Mode Word 



^ ^ 

Mode 1 Bits 1 Meaning 
+ f 

general | 26 | 1 - indicates to phase 20 that this text entry is part of a 
1 1 subscript computation. 
+ 1 _ 

general | 27-28 | 00 - LOGICAL 
1 1 01 - INTEGER 
1 1 10 - REAL or COMPLEX 

_ 1 _ L _ _ ^ _ — _____ _ — _ 


operand 1| 29 ] - short mode ( LOGICAL* 1, INTEGER* 2, REAL* 4, COMPLEX* 8) 
1 1 1 - long mode ( LOGICAL* U, INTEGER* 4, REAL* 8, C0MPLEX*16) 

. _ 1 1 _ ,_ ______ _ _ 


_ ^ _ _^ _ — ,_ — ______ 

operand 2] 30 j - short mode (LOGICAL*!, INTEGER* 2, REAL* 4, COMPLEX* 8) 
1 1 1 - long mode (LOGICAL*^, INTEGER*^, REAL*8, C0MPLEX*16) 
+ + 

operand 3| 31 | - short mode (LOGICAL*!, INTEGER*2, REAL*4, COMPLEX*8) 
1 1 1 - long mode (LOGICAL* 4, INTEGER* 4, REAL* 8, COMPLEX*! 6) 

X X 



PHASE 20 INTERMEDIATE TEXT MODIFICATION 



The intermediate text input to phase 20 
is the output text from phase 15. The 
intermediate text output of phase 20 is of 
the same format as the standard text output 
of phase 15, The format of the phase 20 
output text is illustrated in Figure 55. 



R]j__R2i__and_R3_Fields: The RL, R2, and R3 
fields (each 4 bits long) are filled in by 
phase 20 during register assignment, and 
are referred to by phase 25 during the code 
generation process. The assigned registers 
are the operational registers for operand 
!, operand 2, and operand 3, respectively. 



Bl, B2 , and B3 Fields: The Bl, B2, and B3 
fields (each 4 bits long) are filled in by 
phase 20 during register assignment, and 
are referred to by phase 2 5 during the code 
generation process. The assigned registers 
are the base registers for operand 1, 
operand 2, and operand 3, respectively. 



Status Field ; The status field, the first 
two bytes of the status mode word, is set 
by phase 20 to indicate the status of the 
operands and the status of the base 
addresses of the operands in a text entry. 
The information in the status field is used 
by phase 25 to determine the machine 
instructions that are to be generated for 
the text entry. The status field bits and 
their meanings are illustrated in Table 30. 



■4 bytes- 



Chain field^ 


Status field 
















1 

1 
J 


T 

Operator field^ | 


Mode field^i- 


R! 1 

L 


Bl 


1 

1 
1 














P! 


fieldi 




R2 1 


B2 


1 

1 
1 














P2 


field^ 




R3 1 

_ J 


B3 


1 

1 
1 














P3 


field! 




Displacement 


field^ 






















^The chain field, mode field, operator 
placement field are as defined in a pin 
alter these fields.) 


field, 
lase 15 


PI field, P2 field, 
standard text entry. 


P3 field, and dis- 
( Phase 20 does not 



Figure 55. Format of Phase 20 Text Entry 
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STANDARD TEXT FORMATS RESULTING FROM PHASES 
15 AND 20 PROCESSING 



The following formats illustrate the 
standard text entries developed by phase 15 
and phase 20 for the various types of 
operators. When the fields of the text 



entries differ from the standard defini- 
tions of the fields, the contents of the 
fields are explained. In addition, notes 
that explain the types of instructions 
generated by phase 25 are also included to 
the right of the text entry format, when 
appropriate. For an explanation of the 
individual operators see Table 28. 



• Table 30. Status Field Bits and Their Meanings 

r T T 



T 



K- - 



Operand/ | | 
Base Address | Bit | Meaning 

. _ J. J. , _ 


"■ T T 

1 1 not used 

1 1 1 1 - text item contains inert variable 

1 2 1 - base address in storage 
Operand 2 ] | 1 - base address in register 
base address | j 
status 1 3 1 - do not retain base address in register 

1 1 1 - retain base address in register 
+ 1 

1 4 1 - base address in storage 
Operand 3 j j 1 - base address in register 
base address j | 
status ] 5 ] - do not retain base address in register 

1 1 1 - retain base address in register 
4 ^ 

1 6 ] - operand in storage 

Operand 2 | j 1 - operand in register 

status 1 1 

1 7 1 - do not retain operand in register 
j 1 1 - re:tain operand in register 
+ 1 

1 8 1 - operand in storage 
Operand 3 | 11- operand in register 
status 1 1 

i 9 I - do not retain operand in register 

+ 1 

J 10 j - base address in storage 
Operand 1 | | 1 - base address in register 
base address ] j 

status 1 11 1 - do not retain base address in register 
I 1 1 - retain base address in register 
+ 1 

Operand 1 | 12 | - generate store into operand 1 
status I 1 1 - do not generate store into operand 1 
+ 4 

1 13 1 not used 

1 14 I 1 - divide item actually MOD function. If FC=4 4 

1 1 or 15, load addresses precede. 

1 15 ] 1 - .QXX temporary created for this item 



L JL X J 
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Branch Operator (B) 



■U bytes > 



r 1 

1 Chain J 

L_ 1 


1 Status 




T 

1 Branch 
1 operator 

L _ _ _ 


T 

1 

1 
L _ 


1 

Mode 1 
„ J 


r T ~ 

1 Rl 1 

\- + 

1 1 

1 1 
I _ J. _ 


5 PI 

1 
1 






~ 1 

-1 

■« 

J 


1 1 

L . „ J 



PI; The PI field contains a pointer to the 
statement number/array table entry for the 
statement number to which a branch was 
made. 



Note: Phase 25 decides whether an RR or an 
RX branch instruction should be generated. 



Logical Branch Operators (BT, BF) 



<- 



j Chain 
^ 

1 Status 



j. ^__. 

I Rl I 

\- +— 

1 R2 |B2 
j. +__. 



■4 bytes- 



Pi 



P2 



I Logical 
I branch 
\ operator 

-A 



Mode 



PI: The PI field contains a pointer to the 
statement number/array table entry for the 
statement number to which a branch is being 
made. 



P2; The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 

Note: The test of the logical variable 
will be done with a BXH or BXLE for BT and 
BF, respectively. 



Binary Operators (+, -, *, /, OR, and AND) 



< , 4 bytes 


1 Chain 


] Status 




T 

1 Binary 

1 operator 
J. _ 


T 

1 

1 
L_ 


Mode 


1 Rl |B1 
1 R2 |B2 


jPl 

|P2 
_ 1 








1 R3 |B3 

L ± 


IP3 
—i 
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Test and Set Operators (GT, LT, GE, LE, EQ, 
and NE) 



■ 4 bytes- 



I Chain 
1- 



T T" 

I Test and ) 

I set I 

] operator | 

.X J.. 



Status 



I- T T 

I Rl |B1 I PI 

1- + +— 

I R2 |B2 1P2 
|. 1 +__. 

I R3 1B3 |P3 
L i JL 



Mode 



In-line Functions (MAX2, iyiIN2, DIM, IDIM, 
DMOD, MOD, AMOD, DSIGN, SIGN, ISIGN, LAND, 
LOR, LCOMPL, IDIM, BITON, BITOFF, AND, OR, 
COMPL, M0D2U, SHFTR, and SHFTL) 



• 4 bytes- 



1 Cha 


in 










1 Status 




T~ 

1 Function 
1 operator 

L 


T 

1 

1 
X 


Mode i 


1 Rl 
1 R2 


IBI 

-+ 

1B2 
1 


_ ^ _ 

|P1 
-+ 

|P2 

1 _ 








1 R3 


|B3 

L 


|P3 
. X 










1 


T 

1 
i 









Testing a Byte Logical Variable (LDB) 



I Chain 
J. 



status 



1- T — 

Rl JBl 

I- r-+— 

R2 I B2 

I- +— 

R3 1 B3 

L 



• 4 bytes- 



■T T 

I LDB I Mode 
I operator | 

.X X 



Note: The LDB operator is used to load a 
register with a byte logical variable. 
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Branch on Index Low or Equal, or Branch on 
IncJex High 



•U bytes- 



r 1 

] Chain | 

L J 


1 Status 


1 Add 1 Mode 1 




1 operator] j 

^ _ X _ _ X _J 


I Rl 1 Bl 

] R2 ) B2 

1- + 

1 R3 1 B3 


T ^ 1 

1 PI 1 
_+™ ^ 

1 P2 1 
.^.. ^ 

1 P3 1 


L X 


_X J 



Text 
Entry 1 



Note : A BXHLE instruction will be 
generated by phase 25 when an add operator 
is followed by a branch operator. 



PI and P2 of text entry 1 equals P2 of 
text entry 2, 



■H bytes- 



r* ■ T 

1 Chain | 

L _ J 


j Status 


1 Branch | Mode | 




1 operator} | 

— X _ X _ _ J 


1 Rl 1 

I R2 1 B2 

1 R3 1 B3 


T -^ ~ "^ - - 1 

1 PI 1 

_+_^ ^ 

1 P2 1 
_!_. ^ 

1 P3 1 


L X 


_X J 



Text 
Entry 2 



PI ; The PI field of text entry 2 contains 
a pointer to the statement number/ array 
table entry for the statement number to 
which a branch is being made. 



Computed GO TO Operator 



<- 



i Chain 
j. 

] Status 

I 



I- T- 

1 Rl I 
j. +- 



F- 



R3 



4 bytes- 



-X— 

I PI 

-+— 
1P2 

4— 

|P3 



■T T 

I Computed | Mode 
I GO TO j 
I operator j 
-X X 



PI: PI contains the number of items in the 
branch table that are associated with the 
computed GO TO operator. 



P2: P2 contains a pointer to the informa- 
tion table entry for the branch table. 



P3: P3 contains a pointer to the indexing 
value for the computed GO TO statement. 
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Branch Operators (BL, BLE, BE, BNE, BGE, 
BG, BLZ, BLEZ, BEZ, BNEZ, BGEZ, and BGZ) 



Chain 



Statues 



T 

Rl IBI 



R2 



B2 



■4 bytes- 



-T 

I PI 



P2 



R3 |B3 |P3 

L i i 



-^ ^ 

1 Branch | Mode 
-X ± 



■1 Pl= The PI field contains a pointer to the 
statement number/array table entry for the 

"I statement number to which a branch is being 
made. 



Note ; Operands 2 and 3 must be compared 
before the branch. For the BLZ, BLEZ, BEZ, 
BNEZ, BGEZ, and BGZ operators, operand 3 is 
zero and a test on zero is generated. 



Binary Shift Operators (RS, LS) 



■4 bytes- 



j Chain 



■T T 

I Binary | 
I shift I 
I operator | 

-JL J. 



] Status 



I- T T— 

I Rl |B1 I PI 

^- + +— 

I R2 1B2 |P2 

^ +— 



Mode 



Shift quantity 



Load Address Operator (LA) 



• U bytes- 



Chain 



Status 



\- T T— 

I Rl JBl I PI 



I R2 |B2 I PI 

|. 4 4__. 

I R3 |B3 |P3 

f "■ "■ 

I Displacement 

L 



-T 

I Load 

I address | 

I operator | 

.x_l J. 



Mode 



Note: The purpose of the load address 
operator is to store an address of an ele- 
ment of an array in a parameter list. If 
bit 7 of the status field is 1, the LA 
stores the last argument into the parameter 
list. 



The PI field points to a dictionary 
entry which points to the adcon table. 



LA (14) is always followed by CALL (15) 
or a library function (44). 
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Subscript Text Entry — Case 1 



• 4 bytes- 



r 1 

1 Chain | 
L _ _ J 


1 status 




T T 1 

1 Subscript |Mode | 

1 operator j | 

J. ± J 


1 Rl |B1 

L J. . 


|P1 


J. _ _ a. , _ ^ 

_ _ _ _ J 


1 R2 |B2 


|P2 
_ J 


- - - - -j 

^_ J 


1 R3 1B3 
L X ^ 


|P3 
_ i 


— _ _ ^ 

J 


r — — T 
1 Displacement | 

L J 



P2: The P2 field contains a pointer to the 
dictionary entry for the variable being 
indexed. 



P3 : The P3 field contains a pointer to the 
dictionary entry for the indexing value 
unless the indexing value is a constant; 
then P3 =/= and the displacement field con- 
tains a displacement. 



Subscript Text Entry — Case 2 



•U bytes- 



1 1 

1 Chain j 

L _ J 


r ~ 

} Status 

1 

L _ 




T T T 

j Subscript ] Mode ] 

1 operator j j 

L_ _x _ _J 


r T 

1 1 

|. ^ 

I R2 |B2 

L _ X 


IPl 

|P2 
_ J. 


j._ J. — _ -^ 

^ 

_j 


1 R3 |B3 

L 1 


1P3 


— — -^ 


r — — n 

1 Displacement | 

L ■ J 



Note: For Case 2 subscript text entries, 
the subscript text entry is combined with 
the next text entry to form a single RX 
instruction. (Case 2 will be formed by 
phase 15 only when the second text entry 
has the store operator. Phase 20 will 
change Case 1 text entries to Case 2 text 
entries when appropriate, ) 

PI is zero and either P2 or P3 of the 
next text entry will be zero. 

If the operator of the next text entry 
is a store, the subscript applies to PI. 
If the next operator is not a store, the 
subscript applies to operand =0, 

If the next operator is a 'LIST,' the 
subscript applies to PI for READ or to P2 
for WRITE. 



In-line Routines (DABS, ABS, lABS , IDINT, 
INT, HFIX, DFLOAT, FLOAT, DBLE) 



■ 4 bytes- 



Chain 




_^ J 


Status 


. ^_ _ _ 

1 Operator 

_ X 


-T 1 

j Mode 1 

L _ J 


Rl IBl 

R2 |B2 
_4. 


T 

JPI 
__+ 

|P2 

X — — 


^ 

_ _ J 


T 

1 
X 


t ~ 

|Not used 
— X 


1 

J 
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EXT and LIBF Operators 



< — 



^- 



i— 



Chain 



Status 



T 

Rl I Bl 

F +- 



R2 



B2 



J. 4 

R3 I B3 
L — . X 



■ 4 bytes- 



■T 

I PI 



P2 



|P3 
.X 



•T T 

I Operator |Mode 
.X X 



PI ; PI is zero for the EXT operator of a 
subroutine call. 



P2: The P2 field contains either a pointer 
to the dictionary entry for an external 
function or a subroutine name, or a pointer 
to the IFUNTB entry for a library function. 



P3: The P3 field contains either zero or a 
symbolic register number and a displacement 
that points to the object- time parameter 
list of the external function, library 
function, or subroutine. 



Arguments for Functions and Calls 



■U bytes- 



Chain 


Status 




T 

j Argument 
1 operator 

L_ 


T 

jMode 

1 

X _ _ 


T 
1 

1 


-^ 

JPI 

1P2 
X 






1 
X 


|P3 


(for complex) 





Note: No registers are needed for this 
type of text entry. 

For calls and ABNORMAL functions, PI = 
P2. For NORMAL functions and library func- 
tions, PI = 0. 

See the next text entry for the case of 
complex statements. 



Special Argument Text Entry for Complex 
Statements 



} Chain 
I" 



Status 



Rl 



Bl 



■4 bytes- 



Pi 



} Argument | Mode 
I operator | 
.X : X 



"I Note ; For complex statements, the first 
j text entry of the argument list contains 
"1 the register information for the imaginary 
part of the complex result. 
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Assigned GO TO Operator (BA) 



■ 4 bytes- 



I Chain 
|. 

I Status 

I 

I 

V- 

I 

h 

1 

I" 

I 



R2 JB2 



1P2 
-+— 



.^ ^ 

I Assigned (Mode 
JGO TO I 
I operator | 

.J. J. „- 



P2: The P2 field contains a pointer to the 
variable being used in the assigned GO TO 
statement. 



READ Operator for I/O List 



•U bytes- 



Chain 






|READ 
} operator 
_i _ 


T 

1 

1 
L _. 


Rl 1 Bl 

!._— _ 


— T ~ 

|P1 






T • T 

1 1 


1 
i 


|P3 
i 







PI : The PI field contains a pointer to the 
I/O list for the READ statement. If this 
is an indexed READ, Rl is the register to 
be used. 



Note ; If the P3 field contains a zero, an 
entire array is being read. This causes a 
different instruction sequence to be 
generated. 



WRITE Operator for I/O List 



•4 bytes- 



Chain 


Status 




T 

1 WRITE 
1 operator 

± 


T 

jMode 

1 

_x _ 


Rl |B1 
1 


- 1J- — 

1 






T T 

1 |P2 
4- J- 


T 

1 
X 


|P3 
X 







P2: The P2 field contains a pointer to the 
I/O list for the WRITE statement, Rl and 
Bl are the index and base registers to be 
used for the WRITE. 



No te; If the P3 field contains a zero, an 
entire array is being written. This causes 
a different instruction sequence to be 
generated. 
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Logical Branch Operators (BBT, BBF) 



■4 bytes- 



I Chain 
1- 



Status 




T 

1 Logical 
1 Branch 


-T 

JMode 
1 








1 operator 

X 


1 
x_ 




Rl 1 


|P1 










_ 1 








1B2 


1P2 










_ i. 








1 


|P3 










X 






J 



PI: The PI field contains a pointer to the 
statement number/array table entry for the 
statement number to which a branch is being 
made. 



P2; The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 

P3; The P3 field contains a pointer to the 
dictionary entry for the number of the bit 
being tested. 



LBIT Operator 



Status 



■4 bytes- 



I Chain 

^ ^ ^ 



T 
JLBIT 

operator 
X X 



Mode 



-T 

Rl I Bl ] PI 
j. + ^ 

B2 |P2 
^ + + J 

P3 

L X X . J 



P2: The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 



|. ^ ^ X X ^ P3 



P3: The P3 field contains a pointer to the 
dictionary entry for the number of the bit 
being tested. 
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APPENDIX C: ARRAYS 



The major arrays of the compiler are the 
bit-strip and skeleton arrays, which are 
used by phase 25 during code generation. 
The following illustrations detail the bit- 
strip and skeleton arrays associated with 
the operators of text entries that undergo 
code generation. The skeleton array for 
each operator is illustrated by a series of 
assembly language instructions, consisting 
of a basic operation code, which is modi- 
fied to suit the mode of the operands, and 
by operands, which are in coded form. The 
operand codes and their meanings are, as 
follows ; 

Bn — base register for operand n 

BD — base register used for loading an 
operand's base address 

Rn — operational register for operand n 

X — index register when necessary 



To the right of the skeleton array for 
an operator is the bit-strip array for the 
operator. Each bit strip in the bit- strip 
array consists of a vertical string of 0*s, 
l*s, and X's. A particular strip is 
selected according to the status informa- 
tion, which is shown above that strip. For 
example, if the combined status of operands 
2 and 3 is 1010 (reading downward), the bit 
strip under that status is to be used dur- 
ing code generation. (The status of 
operand 2 is indicated in the first two 
vertical positions, reading downward; the 
status of operand 3 is indicated in the 
second two vertical positions, reading 
downward*^) . The meanings of the various 
bit settings in each bit strip are, as 
follows : 

— The associated skeleton array 

instruction is not to be included as 
part of the machine code sequence. 
If a horizontal line containing all 
zeros apipears after an instruction in 
a skeleton, the zero may be changed 
to a one to perform the desired func- 
tion. This usually happens for base 
register loads and result stores. 

1 — The associated skeleton array 

instruction is to be included as part 
of the machine code sequence. 



X — The associated skeleton instruction 
may or may not be included as part of 
the machine code sequence, depending 
upon whether or not the associated 
base address is to be loaded, or 
whether or not a store into operand 1 
is to be performed. 



lEKVPL: Used for All Subtract Operations 





1 


Skeleton 


— T 1 

i 1 


Index] Instructions 


1 Status 1 




J. . 




L _ _ J 




T 

1 

1 

1 

1 
1 




1 00000000111111111 
1 00001111000011111 
10011001100110011) 
1 01010101010101011 

1 1 


1 


1 


B2,D(0,BD) 


1 1 

JXXXXXXXXOOOOOOOO 1 


2 


|LH 


R2,D(0,B2) 


1 0000111100000000 1 


3 


|LH 


R1,D(X,B2) 


11100000000000000 1 


4 


|L 


B3,D(0,BD) 


IXXOOXXOOXXOOXXOO 1 


5 


|LCR 


R3,R3 


1 0010001000000010 1 


6 


|LR 


R1,R2 


1 00001101000011011 


7 


|LH 


R3,D(0,B3) 


1 01000100010001001 


8 


|LCR 


R1,R3 


|0001000000000000| 


9 


|SH 


R1,D(X,B3) 


11000100010001000 1 


10 


|SR 


R1,R3 


1 01000101011101011 


11 


|AH 


R3,D(X,B2) 


1 0010000000000000 1 


12 


|AH 


R1,D(X,B2) 


1 00010000000000001 


13 


jAR 


R3,R2 


|0000001000000010| 


14 


|L 


B1,D(0,BD) 


1 XXXXXXXXXXXXXXXX 1 


15 


|STH 


R1,D(0,B1) 


1 XXXXXXXXXXXXXXXX 1 




_X_— .- 




—J. J 



lEKVTS: Used for the INT, IDINT, IFIX, and 
HFIX In-Line Routines 



^In some cases, operand 3 does not exist 
and only the status of operand 2 is 
indicated. 



T 




— T 




1 




1 






INT, 






1 






IFIX, 






1 


Skeleton 




HFIX 


IDINT 1 


Index 


1 Instructions 




Status 


Status 1 




1 




1 




J 




1 

1 




1 


0011 
0101 


0011 1 
0101 1 


1 


1 

JSDR 


0,0 




1111 


0000 1 


2 


|L 


B2,D(0,BD) 




xxoo 


xxoo 1 


3 


|LD 


R2,D(0,B2) 




0100 


0100 1 


U 


|LD 


0,D(0,B2) 




1000 


1000 1 


5 


jLDR 


0,R2 




0111 


0111 1 


6 


|AW 


0,60(0,12) 




1111 


1111 1 


7 


|STD 


0,64(0,13) 




1111 


1111 1 


8 


|L 


Rl, 68(0, 13) 




1111 


1111 1 


9 


|BALR 


15,0 




1111 


1111 1 


10 


|BC 


10,6(0,15) 




1111 


1111 1 


11 


|LNR 


R1,R1 




1111 


1111 1 


12 


|L 


B1,D(0,BD) 




xxxx 


xxxx 1 


13 


STH 


R1,D(0,B1) 




xxxx 


xxxx 1 




1 




_1. 




J 
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lEKVAD: Used for the ABS, lABS and DABS 
In-Line Routines 



lEKVFP : 



Used for the SHFTR and SHFTL In- 
Line Routines 



Index 



Skeleton 
Instructions 



L 

LH 

LPR 

L 

STH 



B2,D(0,BD) 

R2,D(0,B2) 

R1,R2 

B1,D(0,BD) 

R1,D(0,B1) 



Status 



0011 
0101 

XXOO 
1100 
1111 

xxxx 
xxxx 



^ f 



lEKVFP: Used for the M0D2U In-Line Routine 
r T T 1 



I 



Index 



Skeleton 
Instructions 



L 
L 

LA 

L 

ST 



B2,D(0,BD) 
R2,D(X,B2) 
R1,0(0,R2) 
B1,D(0,BD) 
R1,D(0,B1) 



Status 



0011 
0101 

XXOO 
1100 
1111 
XXXX 
XXXX 



lEKVTS! 



r ^T- 



Used for the MAX2 and MIN2 In-Line 
Routines 







Skeleton 




Index 


Instructions 


Status 


_j 


L 


_ J 


L — . _ _ 






— 1 


0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 


1 


L 


B2,D(0,BD) 


XXXXXXXXOOOOOOOO 


2 


LH 


R2,D(0,B2) 


0000111100000000 


3 


LH 


R1,D(0,B2) 


1100000000000000 


4 


CR 


Rl,R2 


0000001000000010 


5 


CH 


R3,D(0,B2) 


0001000000000000 


6 


CH 


R1,D(0,B2) 


0010000000000000 


7 


L 


B3,D(0,BD) 


XXOOXXOOXXOOXXOO 


8 


LH 


R3,D(0,B3) 


0100010001000100 


9 


CR 


R2,R3 


0100010101110101 


10 


CH 


R2,D(0,B3) 


0000100000001000 


11 


CH 


R1,D(0,B3) 


1000000010000000 


12 


LR 


R1,R2 


0000110100001101 


13 


LR 


R1,R3 


0001000000000000 


14 


BALR 


15,0 


1111111111111111 


15 


BC 


N,6(0,15)i 


1111111111111111 


16 


LR 


R1,R2 


0000001000000010 


17 


LR 


R1,R3 


0100010101110101 


18 


LH 


Rl,D(0,B2) 


0011000000000000 


19 


LH 


R1,D(0,B3) 


1000100010001000 


20 


L 


B1,D(0,BD) 


XXXXXXXXXXXXXXXX 


21 


STH 

L 


R1,D(0,B1) 

J 


XXXXXXXXXXXXXXXX 

L 



Index 



Skeleton 
Instructions 



L 

L 

LR 

L 

LH 

SRL 

L 

ST 



B2,D(0,BD) 

R2,D2{X,B2) 

R1,R2 

B3,D(0,BD) 

R3,D3(X,B3) 

R1,0(0,R3) 

B1,D(0,BD) 

R1,D(0,B1) 



Status 



^ 

00000000111111111 
00001111000011111 
00110011001100111 
01010101010101011 

I 

XXXXXXXXOOOOOOOO I 
1111111100000000 1 
00001111000011111 
XXOOXXOOXXOOXXOO I 
1100110011001100 1 

11111111111111111 

XXXXXXXXXXXXXXXX I 
XXXXXXXXXXXXXXXX 1 

J 



lEKVAD: Used for the DBLE In-Line Routines 

r T T 1 







Skeleton 




1 Index 


Instructions 


1 Status 


L_ J 


L _ _ 




+ — — 


r i 


r 




1 0011 
1 0101 


1 1 


L 


B2,D(0,BD) 


1 XXOO 


1 2 


SDR 


R1,R1 


1 1111 


1 3 


LER 


0,R2 


1 0010 


1 ^ 


LE 


R1,D(0,B2) 


1 1100 


1 5 


LER 


R2,R1 


1 0100 


1 6 


LDR 


R1,0 


1 0010 


1 7 


LER 


R1,R2 


1 0001 


1 8 


L 


B1,D(0,BD) 


1 xxxx 


1 9 


STD 


R1,D(0,B1) 


1 xxxx 



L 

lEKVTS : 
r T- 


J ± 

Used for DIM and IDIM In-Line 
Routines 

■ J 



I Index I 



Skeleton 
Instructions 



I i-For 

L 



MAX2,N=2; for MIN2,N=4. 



1 


|L 


2 


|LH 


3 


|LH 


4 


jLCR 


5 


|AH 


6 


|L 


7 


ILH 


8 


jLR 


9 


|SH 


10 


|AR 


11 


|SR 


12 


IBALR 


13 


|BC 


14 


|SR 


15 


|L 


16 


ISTH 



L_- 



B2,D( 

R2,D( 

R1,D( 

R1,R3 

R1,D( 

B3,D( 

R3,D( 

R1,R2 

R1,D( 

R1,R2 

R1,R3 

15,0 

10, 6( 

R1,R1 

B1,D( 

R1,D( 



0,BD) 
0,B2) 
0,B2) 

0,B2) 
0,BD) 
0,B3) 

0,B3) 



0,15) 

0,BD) 
0,B1) 



Status 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

XXXXXXXXOOOOOOOO 
0000111100000000 
1101000000000000 
0010001000000010 
0010000000000000 
XXOOXXOOXXOOXXOO 
0100010001000100 
0000110100001101 
1000100010001000 
0000001000000010 
0101010101110101 

1111111111111111 
1111111111111111 
1111111111111111 

XXXXXXXXXXXXXXXX 
XXXXXXXXXXXXXXXX 
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lEKVTS : 



Used for SIGN, ISIGN, and DSIGN 
In-Line Routines 



lEKVAD: Used for COMPL and LCOMPL In-Line 
Routines 



r 7 


[~ 


Skeleton 


— T 1 

1 i 


1 Index 


t Instructions 


1 Status 1 


1- 1 






_+ . ^ 

1 0000000011111111 j 

1 00001111000011111 

|0011001100110011| 

1 01010101010101011 
1 1 


1 1 


L 


B2,D(0,BD) 


1 1 
ixxxxxxxxooooooooj 


1 2 


LH 


R2,D(0,B2) 


1 0000111100000000) 


1 3 


LTR 


R3,, R3 


|0010001000100010| 


1 ^ 


LH 


R1,D(0,B2) 


|1111000000000000| 


1 5 


L 


B3,D(0,BD) 


|XXOOXXOOXXOOXXOO| 


1 6 


LH 


R3,D(0,B3) 


|0100010001000100| 


1 7 


LR 


R1,R2 


1 00000010000000101 


1 8 


LPR 


R1,R2 


1 00001101000011011 


1 9 


LPR 


R1,R1 


1 11010000110100001 


1 10 


LTR 


R3,R3 


1 01010101010101011 


1 11 1 


TM 


128,D(0,B3) 


|1000100010001000| 


1 12 


BALR 


15,0 


|iiiiiiiiiiiiiiii| 


1 13 


BC 


14,6(0,15) 


1 10001000100010001 


1 1^ 1 


EC 


10,6(0,15) 


1 01110111011101111 


1 15 


LNR 


R1,R1 


1 11111111111111111 


1 16 


BC 


15,12(0,15) 


lOOlOOOlOOOlOOOlOj 


1 17 


LPR 


Rl,, Rl 


1 00100010001000101 


1 18 


L 


B1,D(0,BD) 


1 XXXXXXXXXXXXXXXX 1 


1 19 1 

L J 


STH 


R1,D(0,B1) 


1 XXXXXXXXXXXXXXXX 1 

-J. J 



lEKVAD: Used for DMOD and AMOD In-Line 
Routines 



r 1 




Skeleton 


r 

1 


j Index 


Instructions 


1 Status 


1 J 


1 




!_ 


r — 1 






10000000011111111 
10000111100001111 
[0011001100110011 
10101010101010101 

1 


1 1 


L 


B2,D(0,BD) 


1 

1 xxxxxxxxoooooooo 


i 2 


LD 


R2,D(0,B2) 


10000111100000000 


1 3 


LD 


Rl, D(0, B2) 


11111000000000000 




STD 


Rl, Temp^ 


[done by lEKVAD 


1 ^ 1 


L 


B3, D(0, BD) 


1 xxooxxooxxooxxoo 


1 5 


LD 


R3,D(0,B3) 


10100010001000100 


1 6 


LDR 


R1,R2 


10000111111111111 


1 7 1 


DDR 


Rl, R3 


0111011101110111 


1 3 1 


DD 


R1,D(0,B3) 


1000100010001000 


1 9 


AD 


Rl,n(0,12) 


11111111111111111 


1 10 1 


MDR 


Rl, R3 


0111011101110111 


1 11 1 


MD 


R1,D(0,B3) 


11000100010001000 


1 12 1 


LCDR R1,,R1 


1111111111111111 


1 13 1 


AD 


Rl,D(0,B2)i 


1111111100000000 


1 1** 1 


ADR 


R1,R2 


0000000011111111 


1 15 1 


L 


B1,D(0,BD) 


XXXXXXXXXXXXXXXX 


1 16 1 
I — i 


STD 


R1,D(0,B1) 


XXXXXXXXXXXXXXXX 

L _ _ 


1 iWhen 


the 


statuses and hi 


ise address stat- 


1 uses 


of operands 2 and : 


3 are zero, a 


1 store 
I be de 


i of operand 2 into 
me as indicated anc 


a temporary will 
J the add will be 


J from 


the 


temporary local 


;ion. 



r- 




-T- 




Skeleton 


-T- 






Index 




Instructions 




Status 


1 




J_ 






1 




r 




t 






t 


0011 
0101 
0000 
0000 




1 




L 


B2,D(0,BD) 




xxoo 




2 




L 


R2,D(0,B2) 




0100 




3 




LA 


Rl, 1(0,0) 




1101 




^ 




LCR 


R1,R1 




1111 




5 




X 


R1,D2(X,B2) 




1000 




6 




XR 


R1,R2 




0101 




7 




BCTR 


R1,0 




0010 




8 




L 


B1,D(0,BD) 




xxxx 




9 




ST 


R1,D(0,B1) 




xxxx 



lEKVBL: 



I Index j 
j. 4- 



Used for All Branch True and 
Branch False Operations 



Skeleton 
Instructions 



1 JL B2,D(0,BD) 

2 |L R2,D(0,B2) 

3 |SR R3,R3 

4 |L B1,D(0,BD) 

5 JBXH R2,0(R3,B1) 

6 |BXLE R2,0(R3,B1) 
± - 



Status 



IE 


KVUN: 


Used for 


NOT Operations 




1 




— T 




skeleton 


1 






Index 




Instructions 




Status 


H 




-+- 






-+- 


0011 
0101 




1 




L 


B2,D(0,BD) 




XXOO 




2 




LA 


Rl, 1(0,0) 




1101 




3 




BCTR 


R1,0 




0010 




^ 




LCR 


R1,R1 




0010 




5 




X 


R1,D(X,B2) 




1000 




6 




L 


R2,D2(0,B2) 




0100 




7 




XR 


R1,R2 




0101 




8 




L 


B1,D(0,BD) 




xxxx 




9 




ST 


R1,D(0,B1) 




xxxx 



L JL X J 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

0000000000000000 
1111111100000000 
1100110011001100 

1111111111111111 

1111111111111111* 

1111111111111111* 



♦One of these two instructions will be 
added to the bit strip by subroutine 
MAINGN-IEKTA depending on the operation. 
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lEKVUN: Used for All Load Address 
Operations 



lEKVSU: 



Used for Case 1 and Case 2 Sub- 
script Operations 



Index 



Skeleton 
Instructions 



L 

LH 

L 

LA 

L 

ST 

LA 

MVI 



B3,D(0,BD) 
R3,D(0,B3) 
B2,D(0,BD) 



Rl,D(R3,B2) 

B1,D(0,BD) 

R1,D(0,B1) 

0,128(0,0) 

128.D(0.B1) 



Status 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

0000000000000000 
1100110011001100 
0000000000000000 

1111111111111111 

0000000000000000 

1111111111111111 

0000000000000000 
0000111100000000 



lEKVUN: 



Used for All Load Byte Operations 



Index 



Skeleton 
Instructions 



L 

SR 

IC 

L 

ST 



B3,D(0,BD) 

R3,R3 

R3,D(X,B3) 

B1,D(0,BD) 

R3,D(0,B1) 



Status 



H I- 



0000000011111111] 
00001111000011111 
00110011001100111 
OlOlOlOlOlOlOlOlj 

I 

ooooooooooooooooj 

11111111000000001 

11111111111111111 

00000000000000001 
OOOOOOOOOOOOOOOOJ 



lEKVPL: Used for all Half-Word Integer 
Division Operations and for the 
MOD In- Line Routine 



r - - T 


^_ 


1 




Skeleton 




1 Index 


Instructions 


Status 


j. H 

1 





4 


^ 

0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 


1 1 


L 


B2,D{0,BD) 


0000000000000000 


1 2 


LH 


R2,D(0,B2) 


0000111100000000 


1 3 


LH 


R1,D(0,B2) 


1111000000000000 


1 ^ 


L 


B3,D(0,BD) 


0000000000000000 


1 5 


LH 


R3,D(X,B3) 


1100110011001100 


1 6 


LR 


R1,R2 


0000111100001111 


1 7 


SRDA 


Rl, 32(0,0) 


1111111111111111 


1 8 


DR 


R1,R3 


1111111111111111 


1 9 


D 


R1,D(X,B3) 


0000000000000000 


1 10 


L 


B1,D(0,BD) 


0000000000000000 


1 11 


STH 


R1+1,D(0,B1) 


0000000000000000 


1 12 


STH 


R1,D(0,B1)* 


0000000000000000 



J. ± ± ^ 

]* For MOD in-line routine only. | 

L .^ J 



Index j 
X. 



Skeleton 
Instructions 



Status 



Case 1 





1 

1 
1 
1 




10000000011111111 
10000111100001111 
10011001100110011 
10101010101010101 
_J. 




■f ~ 




T 


1 


|L 


B3,D(0,BD) 


10000000000000000 


2 


ILH 


R3,D(0,B3) 


11100110000000000 


3 


|L 


B2,D(0,BD) 


10000000000000000 


4 


ILH 


R2,D(R3,B2) 


11111111100000000 


5 


|L 


B1,D(0,BD) 


10000000000000000 


6 


ISTH 


R2,D(0,B1) 


10000000000000000 


Case 2 




1 
1 
1 
1 




10000000011111111 
10000111100001111 
10011001100110011 
10101010101010101 
_J. 




1 




T 


1 


|L 


B3,D(0,BD) 


10000000000000000 


2 


|LH 


R3,D(0,B3) 


11100110011001100 


3 


|L 


B2,D(0,BD) 


10000000000000000 


^ 


|LH 


R2,D(R3,B2) 


10000000000000000 


5 


|L 


B1,D(0,BD) 


10000000000000000 


6 


ISTH 


R2,D(0,B1) 


10000000000000000 




jj 




_x 



lEKVUN: Used for All Unary Minus 
Operations 



Index 



Skeleton 
Instructions 



Status 



L 

LH 

LCR 

L 

STH 



B2,D(0,BD) 

R2,D2(X,B2) 

R1,R2 

B1,D(0,BD) 

R1,D1(X,B1) 



10000000011111111 
10000111100001111 
10011001100110011 
JOIOIOIOIOIOIOIOI 

I 

10000000000000000 
11111111100000000 

11111111111111111 

10000000000000000 
10000000000000000 



lEKVBL: Used for All Assigned GO TO 
Operations 



Index j 
4- 



Skeleton 1 
Instructions j 



Status 



I 

I 

1 IL 

2 IL 

3 |BCR 
X 



10000000011111111 
10000111100001111 
10011001100110011 
10101010101010101 



B2,D(0,BD) 
R2,D(0,B2) 
15, R2 



10000000000000000 j 

11111111100000000 1 

111111111111111111 

.X J 
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lEKVBL: Used for All computed GO TO 
Operations 



r T 


T 






Skeleton 




1 Index 


Instructions 


Status 


1 1 


[._ _ 


J 


L 


r — — 




— -— — r 








0000000011111111 








0000111100001111 








0011001100110011 








0101010101010101 


1 1 


L 


B3,D(0,BD) 


0000000000000000 


1 2 


L 


R3,D3(0,B3) 


1100110011001100 


1 3 


LR 


Rl,R3 


0101010101010101 


1 4 


LA 


R2,P1(0,0) 


1111111111111111 


1 5 


CLR 


R1,R2 


1111111111111111 


1 6 


BALE 


R2,, 


1111111111111111 


1 7 


SLL 


Rl, 2(0,0) 


1111111111111111 


1 8 


BC 


2,14(0,R2) 


1111111111111111 


1 9 


L 


R2,D(R1,B) 


1111111111111111 


1 10 


BCR 


15, R2 


1111111111111111 



L X X J 



lEKVSU: 
r T- 



Index! 



Used for All Store Operations 

■T 

I 

I Status 



Skeleton 
Instructions 



|L 
JLH 
|L 

JSTH 
.X 



B2,D(0,BD) 
R2,D(0,B2) 
B1,D(0,BD) 
R2,D(X,B1) 



I 00000000 
100001111 
100110011 
101010101 

I 
100000000 

111111111 

100000000 
I 00000000 

.X 



^ 

111111111 

00001111] 
00110011 I 
01010101) 

I 

00000000 I 
00001000 I 
00000000] 
00000000] 
J 



lEKVTS: used for the FLOAT and DFLOAT In- 
Line Routines 







Skeleton 




Index 


1 Instructions 


Status ] 




L 


_ _ 1 


I 4 




r 


— _ — 1 


r 1 

0011 ] 
0101 ] 


1 


l; 


B2,D(0,BD) 


XXOO 1 


2 


LH 


R2,D(0,B2) 


1100 1 


3 


LD 


Rl, 60(0,12) 


1111 ] 


i\ 


STD 


Rl, 72(0, 13) 


1111 1 


5 


LTR 


R2,R2 


1111 ] 


6 


BALR 


15,0 


1111 ] 


7 


] BC 


4,16(0,15) 


1111 ] 


8 


ST 


R2, 76(0, 13) 


1111 1 


9 


AD 


Rl, 72(0, 13) 


1111 ] 


10 


BC 


15,26(0,15) 


1111 1 


11 


LPR 


0,R2 


1111 1 


12 


ST 


0,76(0,13) 


1111 ] 


13 


SD 


Rl, 72(0, 13) 


1111 ] 


in 


L 


B1,D(0,BD) 


XXXX ] 


15 1 


STD 


R1,D(0,B1) 


XXXX ] 



lEKVPL: Used for All Fixed Point Multipli- 
cation Operations 



■i h 







Skeleton 




Index 

L 


L 


Instructions 


Status 

L 


— — r 


_ -^ 








0000000011111111 








0000111100001111 








0011001100110011 








0101010101010101 


1 


L 


B2,D(0,BD) 


0000000000000000 


2 


LH 


R2,D(0,B2) 


0000111100000000 


3 


LH 


R1,D(X,B2) 


1100000000000000 


U 


L 


B3,D(0,BD) 


0000000000000000 


5 


LH 


R3,D(0,B3) 


0100010001000100 


6 


LR 


R1,R2 


0000110100001101 


7 


LR 


R1,R3 


0001000000000000 


8 


MR 


R1-1,R3 


0100010101110101 


9 


MR 


R1-1,R2 


0000001000000010 


10 


MH 


R1,D(X,B3) 


1000100010001000 


11 


MH 


R1,D(X,B2) 


0011000000000000 


12 


L 


B1,D(0,BD) 


0000000000000000 


13 


STH 


R1,D(0,B1) 


0000000000000000 



L X X J 



lEKVAD : 



Index 



Used for the AND and OR In-Line 
Routines 



|. 4 4 ^ 

0000000011111111 
0000111100001111 
0011001100110011 

oidioioioioioioi 



Skeleton 
Instructions 



L 
L 
L 
N 
L 
ST 



B2,D(0,BD) 
R1,D(X,B2) 
B3,D(0,BD) 
R1,D(X,B3) 
B1,D(0,BD) 
R1,D(0,B1) 



Status 



0000000000000000 
1111111100000000 
0000000000000000 

1111111111111111 

0000000000000000 
0000000000000000 



lEKVSU: Used for All Right- and Left-Shift 
Operations 



Index 



Skeleton 
Instructions 



L 

LH 

LR 

SRA 

HDR 

L 

STH 



B2,D(0,BD) 

R2,D(0,B2) 

R1,R2 

R1,P3(0,0) 

R1,R2 

B1,D(0,BD) 

R1,D(0,B1) 



Status 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

0000000000000000 
1111111100000000 
0000111100001111 

1111111111111111 

0000000000000000 
0000000000000000 
0000000000000000 
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lEKVPL: 



r 

Index 



Used for all Full-Word Integer 
Division Operations and for the 
MOD In-Line Routine 



+ + ^ 

0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 



1 

2 
3 

u 

5 

6 

7 

8 

9 

10 

11 

12 



Skeleton 
Instructions 



-T 



Status 



1 



L 

LH 

LH 

L 

LH 

LR 



B2 
R2 
Rl 
B3 
R3 
Rl 



SRDA Rl 
DR Rl 



Rl 
Bl 



STH Rl 
STH Rl 



,D(0, 

#D(0, 

,D(0, 

,D(0, 

,D(X, 

.,#R2 

,32(0 

,R3 

_,D(X, 

-»DCO, 

. + 1,D( 

,D(0, 



BD) 
B2) 
B2) 
BD) 
B3) 

rO) 

B3) 
BD) 
0,B1) 
BD* 



0000000000000000 
0000111100000000 
1111000000000000 
0000000000000000 
0100010001000100 
0000111100001111 

1111111111111111 

0111011101110111 
1000100010001000 
0000000000000000 
0000000000000000 
0000000000000000 



j ♦ For MOD in-line 

L . 



routine only. 



H 



lEKVUN: Used for All Logical Operations 

r T r 1 

Skeleton 
Instructions 



Index 



1 

2 

3 

H 

5 

6 

7 

8 

9 

10 

11 

12 

13 



L 

L 

L 

L 

L 

L 

LR 

NR 

NR 

N 

N 

L 

ST 



4- 



B2,D(0,BD) 

R2,D(0,B2) 

R1,D2(0,B2) 

B3,D(0,BD) 

R3,D(0,B3) 

R1,D3(X,B3) 

R1,R2 

R1,R2 

R1,R3 

R1,D2(0,B2) 

Rl,D3(X,B3) 

B1,D(0,BD) 

R1,D1(0,B1) 



Status 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

0000000000000000 
0000111100000000 
1101000000000000 
0000000000000000 
0100010001000100 
0000100000001000 
0000010100000101 
0000101000001010 
0101010101110101 
0010000000000000 
1000000010000000 
0000000000000000 
0000000000000000 



lEKVPLs Used for All Addition Operations 
and for Real Multiplication and 
Real Division Operations 



lEKVTS; Used to Compare Operands Across a 
Relational Operator and Set the 
Result to True or False 



Index 



Skeleton 
Instructions 



1 


L 


B2 


2 


LH 


R2 


3 


L 


B3 


H 


LH 


R3 


5 


CH 


R2 


6 


CR 


R2 


7 


LA 


Rl 


8 


BALR 


15 


9 


BC 


M, 


10 


SR 


Rl 


11 


L 


Bl 


12 


ST 


Rl 



,D(0,BD) 

,D(X,B2) 

,D(0,BD) 

,D(0,B3) 

,D(X,B3) 

,R3 

,1(0,0) 

,0 

6(0,15) 

,R1 

,D(0,BD) 

,D(0,B1) 



Status 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

0000000000000000 
1111111100000000 
0000000000000000 
0100010001000100 
1000100010001000 
0111011101110111 

1111111111111111 
1111111111111111 
1111111111111111 
1111111111111111 

0000000000000000 
0000000000000000 



^ I 



Index 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 



Skeleton 
Instructions 



L 

LH 

LH 

L 

LH 

LH 

LR 

AR 

AR 

AH 

AH 

L 

STH 



B2,D(0,BD) 

R2,D(0,B2) 

R1,D(X,B2) 

B3,D(0,BD) 

R3,D(0,B3) 

R1,D(X,B3) 

R1,R2 

R1,R2 

R1,R3 

R1,D(X,B2) 

R1,D(X,B3) 

B1,D(0,BD) 

R1,D(0,B1) 



Status 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

XXXXXXXXO 0000000 
0000111100000000 
1101000000000000 
XXOOXXOOXXOOXXOO 
0100010001000100 
0000000000000000 
0000110100001101 
0000001000000010 
0101010101110101 
0010000000000000 
1000100010001000 
XXXXXXXXXXXXXXXX 
XXXXXXXXXXXXXXXX 



I — 

Note; For real multiplication and divi- 



sion operations, the basic operation 
codes will be replaced by the required 
codes. 
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lEKVBL: Used for Text Entries Whose Opera- 
tor is a Relational Operator 
Operating on Two Nonzero Operands 



Index 



1 

2 

3 

4 

5 

6 

7 

8* 

9 



Skeleton 
Instructions 



|L B2,D(0,BD) 

JLH R2,D(0,B2) 

|L B3,D(0,BD) 

ILH R3,D(X,B3) 



B2,D( 

R2,D( 

,xj B3,Dtv,.^i^, 

|LH R3,D(X,B3) 

|CH R2,D(X,B3) 

|CR R2,R3 

I T nro TJ o -no 



LTR 

L 

BCR 



R2,R2 
R1,P1 
M,R1 



Status 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

0000000000000000 
1111111100000000 
0000000000000000 
0100010001000100 
1000100010001000 
0111011101110111 
0000000000000000 

1111111111111111 
1111111111111111 



^ k 



♦lEKVBL will generate instruction 8 only 
if PI points to a B- block. 



lEKVBL: Used for Text Entries Whose Opera- 
tor is a Relational Operator 
Operating on One Operand and Zero 



Index 



1 
2 
3 

5 

6 

7 

8* 

9 



Skeleton 
Instructions 



L 

LH 

L 

LH 

CH 

CR 

LTR 

L 

BCR 



B2,D(0,BD) 

R2,D(0,B2) 

B3,D(0,BD) 

R3,D(X,B3) 

R2,D(X,B3) 

R2,R3 

R2,R2 

R1,P1 

M,R1 



Status 



0000000011111111 
0000111100001111 
0011001100110011 
0101010101010101 

0000000000000000 
1111111100000000 
0000000000000000 
0000000000000000 
0000000000000000 
0000000000000000 

1111111111111111 
1111111111111111 
1111111111111111 



♦lEKVBL will generate instruction 8 only 
if PI points to a B-block. 



lEKVFP: Used for the LBIT, BBT, and BBF In- Line Routines 



K 









1 


BBT, 


BBF 


1 




LBIT 






Skeleton 
Instructions 


H 








4— 








Index 


Simple 
Variable 


1 


Subscripted 
Variable 


T 


Simple 
Variable 


— T 


Subscripted 
Variable 


_j 






1 




1 




L 




- 4— 




— 1 

1 


L 


B2,D(0,BD) 


i 


X 


1 


X 


r 


X 


T 


X 


2 


LA 


15,D+N/8(X,B2) 









1 









1 


3 


TM 


M,D+N/8(B2) 




1 









1 







U 


TM 


M,0(15) 









1 









1 


5 


TM 


M, D+N/8(R2) 






















6 


L 


15, PI 




1 




1 












7 


BCR 


MM, 15 




1 




1 












8 


BALR 


15,0 














1 




1 


9 


LA 


Rl, 1(0,0) 














1 




1 


10 


BC 


1,10(0,15) 














1 




1 


11 


SR 


R1,R1 














1 




1 


12 


L 


B1,D(0,BD) 














X 




X 


13 


ST 


R1,D(0,B1) 














X 




X 



Y X x_.„ X X X ^ 

N = The bit to be loaded or tested. 

M = MSKTBL(MOD(N, 8)+l). MSKTBL is an array of masks used by lEKVFP. 
MM = 1 FOR BBT. 
MM = 8 FOR BBF. 

L ., . J 
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APPENDIX D: TEXT OPTIMIZATION EXAMPLES 



This appendix contains examples that illustrate the effects of text optimization on 
sample text entry sequences. An example is presented for each of the four sections of 
text optimization. 



Example 1; Common Expression Elimination 

This example illustrates the concept of common expression elimination. The text 
entries in block A are to undergo common expression elimination. Block B is a back 
dominator of block A. Block B contains text entries that are common to those in block A. 



0) 



(2) 



(3) 



Block B 



Tl = I * 4 


T2 = J * 12 


T3 = T1 +T2 


T4 = X (s T3 


A =T4 + Y 


Block A , 




T7 = 1 * 4 


T8=J * 12 


T9 = T7 + T8 


TIO = X (s T9 


B == TIO + Z 



Eliminate 
T7 = I * 4 



(4) 



Unchanged 


A 




T8 = J * 12 


T9= Tl +T8 


TIO = X (s T9 


B= TIO + Z 



Eliminate 
T8 = J * 12 



Unchanged 



(5) 



T9 = T1 +T2 
TIO = X (s T9 
B = T10 + Z 



Eliminate 
T9 = Tl + T2 



Unchanged 



Eliminate 
T10 = X (sT3 



Unchanged 



TIO = X (s T3 
B = T10 + Z 



= T4 + Z 



NOTE: The items Ti are temporaries and (s represents a subscript operator 
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Example 2; Backward Movement 



This example illustrates both 
methods of backward movement. 
The text entries in block A are 
to undergo backward movement. 
Block B is the back target of the 
loop containing block A. 



Block B 



(1) 



(2) 



E = W+ Z 


A 


X = E + U 


T1 =A + B 


T2 = Tl + C 


E = T2 + D 



Move 

Tl = A + B 



E = W + Z 



Tl =A + 



Move 

T2 = Tl + C 



X = E + U 



T2 = Tl + C 
E = T2 + D 



(3) 



(4) 



E = W+ Z 



Tl = A + B 
T2 = Tl + C 



Move the 
expression 
T2+ D 



X = E + U 



E = T2 + D 



E = W+Z 


Tl'=A + B 


T2 = Tl + C 


Tj = T2 + D 






A 


X "= E '+ U 


E = Ti 



NOTE: The text entry X = E + U cannot be moved, because its operand 2 is 
defined elsewhere in the loop. The text entry E = T2 + D cannot be 
moved, because operand 1 (E) is busy-on-exit from the back target; 
however, the expression T2 + D can be moved. 
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Example 3; Si mple - S tore Elimination 



The following example illustrates the concept of simple-store elimination, an 
integral part of the processing of backward movement. 



r — 





(1) 




• 


. . 




z 


= X 




A 


= Z + 


B 


D 


= F * 


Z 


X 


= 2 * 


M 


Z 


-Y/ 


4 


N 


= Z + 


G 


• ■ 


• • 





(2) 



Eliminate Z = X 



A = X + B 

D = F * X 

X = 2 * M 

Z = Y/4 



N = Z+ G 



Y ^ 



L-., 



Hote; Uses of operand 1 of the simple store that appear below the redefinition of 
either operand of the simple store are not replaced. 
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Exa m ple U; Str e ngth Reduction 

This example illustrates both methods of strength reduction. In the example, 
strength reduction is applied to a DO loop. The evolution of the text entries that 
represent the DO loop and the functions of these text entries are also shown. The for- 
mats of the text entries in all cases are not exact. They are presented in this manner 
to facilitate understanding. 

Consider the DO loop: 



10 



1=3 

DO 10 J=l,3 

A=X(I, J) 

CONTINUE 



As a result of the processing of phases 10 and 15, and backward movement, the DO loop 
has been converted to the following text representation. 



Function 



r * T — 

I Text Entry | 

.__. + . 

1 = 3 I Initializes I 



Evolution 



Back 
Target 



Loop 



J = 1 



Tl = I ♦ a 



T2 = J ♦ 12 



T3 = Tl + T2 



A = X (S T3 



J = J + 1 



IF(J<3)GOTO Y 



Initializes J 



Multit)lies first 
subscript parameter 
by its dimension 
factor 



Multiplies second 
subscript parameter 
by its dimension 
factor. 

Computes index value 
for the subscripted 
variable X. 



Stores X(I,J) into A 



Increments DO index. 



Tests DO index 
against its maximum 
and controls branch- 
ing. 



Stated in source module, converted to 
phase 10 text and then to phase 15 text. 
It resides in the back target of the loop 
because of text blocking. 

Generated phase 10 text entry, converted 
to phase 15 text entry. It resides in the 
back target of the loop because of text 
blocking. 

Generated by phase 15 when it encounters 
the siibscript parameter I during its 
processing of phase 10 text. It resides 
in the back target of the loop as a 
result of the processing of backward 
movement. 



"I 



Generated by phase 15 when it encounters 
the subscript parameter J during its 
processing of phase 10 text. 



Generated by phase 15 after the last sub- 
script parameter in the phase 10 text 
representation of the subscripted vari- 
able has been processed. 

The phase 10 text entry forced and con- 
verted to phase 15 text after the index 
value for the subscripted variable has 
been established. 

Generated by phase 10 and converted to 
phase 15 text representation. 

Generated by phase 10 and converted to 
phase 15 text representation. 



Note: The statement number Y is generated by phase 10. Also, it is assumed 



that the array X is of the format X(3,3) and that its elements are real 
(length U). 
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The following illustration shows the application of strength reduction to the loop. 



0) 



I =3 
J = 1 
Tl =1 



Eliminate 
MultiplicaHve 
Text from Loop 



Y T2 = J * 12 
T3 = Tl + T2 
A = X (s T3 
J =J + 1 
IF (J<3) GOTOY 




(3) 



Eliminate 

Additive 

Text from Loop 



1 = 3 


J = 1 


n := 1 * 4 


M=J * 12 


N = 36 + Tl 


P = T1 +M 



Y T3 = Tl + M 
A = X (s T3 
M = M+ 12 
IF (M<36) GOTOY 



Y A = X (s P 
P= P+ 12 
IF (P:^N) GOTOY 
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APPENDIX E: OBJECT-TIME LIBRARY SUBPROGRAMS 



This appendix describes the logic of 
some of the object- time library subprograms 
that may be referenced by the FORTRAN load 
module. Included at the end of this appen- 
dix are flowcharts that describe the logic 
of the subprograms. 

Each object module, compiled from a 
FORTRAN source module, must be processed by 
the linkage editor prior to execution on 
the IBM System/360. The linkage editor 
must combine certain FORTRAN library sub- 
programs with the object module to form an 
executable load module. The library sub- 
programs exist as separate load modules on 
the FORTRAN system library (SYSl.FORTLIB) . 
Each library subprogram to which reference 
is made externally by the object module is 
included in the load module by the linkage 
editor. Among the library subprograms to 
which references may be made are: 

• IHCFCOMH (object-time input/output 
source statement processor) — entry 
name IBCOM#. If the 'extended error 
message facility is specified, this 
module is replaced by IHCECOMH. 

• IHCFIOSH (object-time sequential access 
input/ output data management interface) 

— entry name FIOCS#. If the extended 
error message facility is specified, 
this module is replaced by IHCEFIOS. 

• IHCNAMEL (object-time namelist rou- 
tines) — entry names FRDNL# and 
FWRNL#. 

• IHCDIOSE (object-time direct access 
input/ output data management interface) 

— entry name DIOCStt. If the extended 
error message facility is specified, 
this module is replaced by IHCEDIOS. 

• IHCIBERH (object- time source statement 
error processor) — entry name IBERH#. 

• IHCFCVTH (object-time conversion rou- 
tine) — entry name ADCON#. 

• IHCTRCH (object-time terminal error 
message and diagnostic traceback rou- 
tine) — entry name IHCTRCH. If the 
extended error message facility is 
specified, this module is replaced by 
IHCETRCH. 



IHCFINTH (object-time program interrupt 
processor). If the extended error mes- 
sage facility is specified, this module 
is replaced by IHCEFNTH. 

IHCERRM (object-time error message 
processor. The module monitors all 
execution time errors). 

IHCADJST (object-time boundary adjust- 
ment routine) — entry name IHCADJST. 



Module names used in the following dis- 
cussions are those in effect when the 
extended error message facility has not 
been specified. However, the descriptions 
apply also with the extended error message 
facility, unless otherwise stated. 



Subprogram IHCFCOMH receives input/ 
output requests from the FORTRAN load 
module via compiler-generated calling 
sequences. IHCFCOMH, in turn, submits 
these requests to the appropriate data 
management interface (IHCFIOSH or 
IHCDIOSE). 

The IHCFIOSH subprogram receives sequen- 
tial access input/output requests from IHC- 
FCOMH and, in turn, submits those requests 
to the appropriate BSAM (basic sequential 
access method) routines for execution. 

Subprogram IHCDIOSE receives direct 
access input/output requests from IHCFCOMH 
and, in turn, submits those requests to the 
appropriate BDAM (basic direct access 
method) routines for execution. 

If source statement errors are detected 
during compilation, the compiler generates 
a calling sequence to the IHCIBERH subpro- 
gram. The IHCIBERH subprogram processes 
object-time errors resulting from improper- 
ly coded source statements. Subprogram 
IHCFCVTH contains the various object-time 
conversion routines required by IHCFCOMH 
and IHCNAMEL. The IHCTRCH subprogram proc- 
esses terminal object-time error messages 
and produces a diagnostic traceback for 
IHCFCOMH. Subprogram IHCADJST processes 
object-time specification exceptions if the 
boundary alignment option is specified by 
the user during system generation. 
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IHCFCOMH 



The IHCFCOMH subprogram performs object- 
time implementation of the following FOR- 
TRAN source statements. 



j FORTRAN 
I Load 
I Module 
L ^- 



• READ and WRITE (for sequential 
input/output) . 

• READ,, FIND, and WRITE (for direct 
access input/output) . 

• BACKSPACE, REWIND, and ENDFILE (sequen- 
tial input/output device manipulation) . 

• STOP and PAUSE (write-to-operator) • 



In addition, the IHCFCOMH subprogram: 
(1) initializes arithmetic- type program 
interruptions, and (2) terminates load 
module execution. 

All linkages from the load module to 
subprogram IHCFCOMH are compiler generated. 
Each time one of the above-mentioned source 
statements is encountered during compila- 
tion, the appropriate calling sequence to 
IHCFCOMH is generated and is included as 
part of the object module. At object- time, 
these calling sequences are executed, and 
control is passed to IHCFCOMH to perform 
the specified operation. 



Note ; Subprogram IHCFCOMH itself does not 
perform the actual reading from or writing 
onto data sets. It submits requests for 
such operations to the appropriate input/ 
output data management interface (IHCFIOSH 
or IHCDIOSE ) . The input/output interface, 
in turn, interprets and submits the 
requests to the appropriate access method 
(BSAM or EDAM) routines for execution. 
Figure 56 illustrates the relationship 
between IHCFCOMH and the input/output data 
management interfaces. 



Input/Output j 
Request j 



Submit 

Sequential 

Access 

Input/Output 

Request to 

IHCFIOSH 



r "■ 1 r ^1 

I IHCFCOMH I JIHCFCVTH | 
I (Determine j- — ^ Conversion! 
(Request type) | j Routines j 

L__ ^_J L J 



Submit 
Direct 
Access 

Input /Output 
Request to 
IHCDIOSE 



r — ■ "-1 

I IHCFIOSH j 
I (Sequential j 
I Access I/O I 
I Interface) | 
L , J 



Interpret 
and submit 
Request to 
Appropriate 
BSAM Routine 



I BSAM I 
j Routines j 



r-x -, 

I IHCDIOSE I 
I (Direct | 
I Access I/O I 
I Interface) j 
L ._, J 



Interpret 
and submit 
Request to 
Appropriate 
BSAM/BDAM 
Routine 



r ■- * 1 

I BSAM/BDAM | 

I Routines j 
L , J 



Figure 56. Relationship Between IHCFCOMH 
and Input/Output Data Manage- 
ment Interfaces 



Charts 23, 24, and 25 illustrate the 
overall logic and the relationship among 
the routines of IHCFCOMH. Table 38, the 
IHCFCOMH routine directory, lists the rou- 
tines used in subprogram IHCFCOMH and their 
functions. 

The routines of the IHCFCOMH subprogram 
are divided into the following categories : 

« Read/write routines. 

• Input/output device manipulation 
routines. 

« Write-to-operator routines. 

« Utility routines. 



The read/write routines implement both 
the sequential input/output statements 
(READ and WRITE) and the direct access 
input/output statements (READ, FIND, and 
WRITE) . (The direct access FIND statement 
is treated as a READ statement without for- 
mat and list. ) 



The input/output device manipulation 
routines implement the BACKSPACE, REWIND, 
and END FILE source statements for sequen- 
tial data sets. These statements are 
ignored for direct access data sets. 



The write-to-operator routines implement 
the STOP and PAUSE source statements. 
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The utility routines: (1) process 
errors detected by FORTRAN library subpro- 
grams, (2) process arithmetic- type program 
interrupts, and (3) terminate load module 
execution. 



READ/WRITE ROUTINES 



The READ/WRITE routines of IHCFCOMH 
implement the various types of READ/WRITE 
statements of the FORTRAN IV language. For 
simplicity, the discussion of these rou- 
tines is divided into two parts: 



• READ/WRITE statements not using 
NAMELIST. 

• READ/WRITE statements using NAMELIST. 



READ/WRITE Statements Not Using NAMELIST 



For the implementation of both sequen- 
tial and direct access READ and WRITE 
statements, the read/write routines of IHC- 
FCOMH consist of the following three 
sections: 



• An opening section,, which initicilizes 
data sets for reading and writing. 



• An I/O list section, which transfers 
data from an input buffer to the I/O 
list items or from the I/O list items 
to an output buffer. 

• A closing section, which terminates the 
I/O operation. 



Within the discussion of each section, a 
read/write operation is treated in one of 
two ways: 

• As a read/write requiring a format. 

• As a read/write not requiring a format. 

Note: In the following discussion, the 
term "read operation" implies both the 
sequential access READ statement and the 
direct access READ and FIND statements. 
The term "write operation" implies both the 
sequential access WRITE statement and the 
direct access WRITE statement. 



OPENING SECTION : The compiler generates a 
calling sequence to one of four entry 
points in the opening section of the 
IHCFCOMH subprogram each time it encounters 
a READ or WRITE statement in the FORTRAN 
source module. These entry points corres- 
pond to the operations of read or write, 
requiring or not requiring a format. 

Read/Write Requiring a Format ; If the 
operation is a read requiring a format, the 
opening section passes control to the 
appropriate input/output data management 
interface to initialize the unit number 
specified in the READ statement for read- 
ing. (The unit niamber is passed, as an 
argument, to the opening section via the 
calling sequence. ) The input/output inter- 
face: (1) opens the data control block 
(via the OPEN macro instruction) for the 
specified data set if it was not previously 
opened, and (2) reads a record (via the 
READ macro instruction) containing data for 
the I/O list items into an input/output 
buffer that was obtained when the data con- 
trol block was opened. The input/output 
interface then returns control to the open- 
ing section of subroutine IHCFCOMH. The 
address of the buffer and the length of the 
record read are passed to IHCFCOMH by the 
input/output interface. These values are 
saved for the I/O list section of IHCFCOMH. 
The opening section then passes control to 
a portion of IHCFCOMH that scans the FORMAT 
statement specified in the READ statement. 
(The address of the FORMAT statement is 
passed, as an argument, to the opening sec- 
tion via the calling sequence. ) The first 
format code (either a control or conversion 
type) is then obtained. 

For control type codes (e.g., an H for- 
mat code or a group count) , an I/O list 
item is not required. Control passes to 
the routine associated with the control 
code under consideration to perform the 
indicated operation. Control then returns 
to the scan portion, and the next format 
code is obtained. This process is repeated 
until either the end of the FORMAT state- 
ment or the first conversion code is 
encountered. 

For conversion type codes (e.g., an I 
format code) , an I/O list item is required. 
Upon the first encounter of a conversion 
code in the scan of the FORMAT statement, 
the opening section completes its process- 
ing of a read requiring a format and 
returns control to the next sequential 
instruction within the load module. 

The action taken by IHCFCOMH when the 
various format codes are encountered is 
illustrated in Table 31. 
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Table 31. The IHCFCOMH Subprogram FORMAT Code Processing 

I T T T 



FORMAT code 



Description 



Type 



Corresponding Action Upon Code by IHCFCOMH 



n( 



nP 



Tn 



nX 



•text* or nH 



Fw. d 
Ew. d 
Dw. d 
Iw 
Aw 
Gw. d 
Lw 
Zw 



beginning of 
statement 



group count 



field count 



scaling factor 



column reset 



skip or blank 



literal data 



F-conversion 
D-conversion 
D-conversion 
I-conversion 
A-conversion 
G- conversion 
L- conversion 
Z-conversion 



control 



control 



control 



control 



control 



control 



control 



conversion 
conversion 
conversion 
conversion 
conversion 
conversion 
conversion 
conversion 



group end 



record end 



end of 
statement 



control 



control 



control 



Save location for possible repetition of the 
format codes; clear counters. 



Save n and location of left parenthesis for 
possible repetition of the format codes in the 
group. 



Save n for repetition of format code that 
follows. 



Save n for use by F, E, and D conversions. 



Reset current position within record to nth 
column or byte. 

Skip n characters of an input record or insert n 
blanks in an output record. 



Move n characters from an input record to the 
FORMAT statement, or n characters from the 
FORMAT statement to an output record. 



Exit to the load module to return control to 
entries FIOLF or FIOAF in subprogram IHCFCVTH. 
Using information passed to the I/O list 
section, the address and length of the current 
list item are obtained and passed to the 
proper conversion routine together with the 
current position in the input/output buffer, the 
scale factor, and the values of w and d. Upon 
return from the conversion routine, the current 
field count is tested. If it is greater than 1, 
another exit is made to the load module to 
obtain the address of the next list item. 



Test group count. If greater than 1, repeat 
format codes in group; otherwise, continue 
to process FORMAT statement from current 
position. 



Input or output one record via the input/output 
interface and READ/WRITE macro instruction. 



If no I/O list items remain to be transmitted, 
return control to the load module to link to the 
closing section; if list items remain, input or 
output one record using input/output interface 
and READ/WRITE macro instruction. Repeat 
format codes from last parenthesis. 
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If the operation is a write requiring a 
format, the opening section passes control 
to the input/output interface to initialize 
the unit number specified in the WRITE 
statement for writing. (The unit number is 
passed, as an argument, to the opening sec- 
tion via the calling sequence. ) The input/ 
output interface opens the data control 
block (via the OPEN macro instruction) for 
the specified data set if it was not pre- 
viously opened. The input/output interface 
then returns control to the opening section 
of IHCFCOMH. The address of an input/ 
output buffer that was obtained when the 
data control block was opened is saved for 
the I/O list section of IHCFCOMH. Subse- 
quent opening section processing, starting 
with the scan of the FORMAT statement, is 
the same as that described for a read 
requiring a format. 



The selected conversion routine obtains 
data from an input buffer and converts the 
data to the form dictated by the conversion 
code. The converted data is then moved 
into the main storage address assigned to 
the list item. 



In general, after a conversion routine 
has processed a list item, the I/O list 
section determines whether that routine can 
be applied to the next list item or array 
element (if an array is being processed). 
The I/O list section examines a field count 
that indicates the number of times a par- 
ticular conversion code is to be applied to 
successive list items or successive ele- 
ments of an array. 



Read/Wr ite Not Requiring a Format; If the 
operation is a read or write not requiring 
a format, the opening section processing 
except for the scan of the FORMAT statement 
is the same as that described for a read or 
write requiring a format. (For a read or 
write not requiring a format, there is no 
FORMAT statement. ) 



If the conversion code is to be repeated 
and if the previous list item was a vari- 
able, the I/O list section returns control 
to the load module. The load module again 
branches to the I/O list section and 
passes, as an argiament, the main storage 
address assigned to the next list item. 



I/O LIST SECTION ; The compiler generates a 
calling sequence to one of four entry 
points in the I/O list section of subpro- 
gram IHCFCOMH each time it encotanters an 
I/O list item associated with the READ or 
WRITE statement under consideration. These 
entry points correspond to a variable or an 
array list item for a read and write, 
requiring or not requiring a format. The 
I/O list section performs the actual 
transfer of data from; (1) an input buffer 
to the list items if a READ statement is 
being implemented, or (2) the list items to 
an output buffer if a WRITE statement is 
being implemented. In the case of a read 
or write requiring a format, the data must 
be converted before it is transferred. 



The conversion routine that processed 
the previous list item is then given con- 
trol. This procedure is repeated until 
either the field count is exhausted or the 
input data for the READ statement is 
exhausted. 



If the conversion code is to be repeated 
and if an array is being processed, the I/O 
list section computes the main storage 
address of the next element in the array. 
The conversion routine that processed the 
previous element is then given control. 
This procedure is repeated until either all 
the array elements associated with a spe- 
cific conversion code are processed or the 
input data for the READ statement is 
exhausted. 



R ead/Write Requiring a Format : In process- 
ing a list item for a read requiring a for- 
mat, the I/O list section passes control to 
the conversion routine associated with the 
conversion code for the list item. (The 
appropriate conversion routine is deter- 
mined by the portion of subprogram IHCFCOMH 
that scans the FORMAT statement associated 
with the READ statement. The selection of 
the conversion routine depends on the con- 
version code of the list item being 
processed. ) 



If the conversion code is not to be 
repeated, control is passed to the scan 
portion of subprogram IHCFCOMH to continue 
the scan of the FORMAT statement. If the 
scan portion determines that a group of 
conversion codes is to be repeated, the 
conversion routines corresponding to those 
codes are applied to the next portion of 
the input data. This procedure is repeated 
until either the group count is exhausted 
or the input data for the READ statement is 
exhausted. 
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If a group of conversion codes is not to 
be repeated and if the end of the FORMAT 
statement is not encountered, the next for- 
mat code is obtained. For a control type 
code, control is passed to the associated 
control routine to perform the indicated 
operation. For a conversion type code, 
control is returned to the load module if 
the previous list item was a variable. The 
load module again branches to the I/O list 
section and passes, as an argument, the 
main storage address assigned to the next 
list item. Control is then passed to the 
conversion routine associated with the new 
conversion code. The conversion routine 
then processes the data for this list item. 
If the data that was just converted was 
placed into an element of an array and if 
the entire array has not been filled, the 
I/O list section computes the main storage 
address of the next element in the array 
and passes control to the conversion rou- 
tine associated with the new conversion 
code. The conversion routine then proc- 
esses the data for this array element. 
Subsequent I/O list processing for a READ 
requiring a format proceeds at the point 
where the field count is examined. 



Read/W r ite Not Requiring a Format ; In 
processing a list item for a read not 
requiring a format, the I/O list section 
must know the main storage address assigned 
to the list item and the size of the list 
item. Their values are passed, as argu- 
ments, via the calling sequence to the I/O 
list section. The list item may be either 
a variable or an array. In either case, 
the number of bytes specified by the size 
of the list item is moved from the input 
buffer to the main storage address assigned 
to the list item. The I/O list section 
then returns control to the load module. 
The load module again branches to the I/O 
list section and passes, as arguments, the 
main storage address assigned to the next 
list item and the size of the list item. 
The I/O list section moves the number of 
bytes specified by the size of the list 
item into the main storage address assigned 
to this list item. This procedure is 
repeated either until all the list items 
are satisfied or until the input data is 
exhausted. Control is then returned to the 
load module. 



If the scan portion encounters the end 
of the FORMAT statement and if all the list 
items are satisfied, control returns to the 
next sequential instruction within the load 
module. This instruction (part of the 
calling sequence to subprogram IHCFCOMH) 
branches to the closing section. If all 
the list items are not satisfied, control 
is passed to the input/output interface to 
read (via the READ macro instruction) the 
next input record. The conversion codes 
starting from the last left parenthesis are 
then repeated for the remaining list items. 



If the operation is a write requiring a 
format, the I/O list section processing is 
similar to that for a read requiring a for- 
mat. The main difference is that the 
conversion routines obtain data from the 
main storage addresses assigned to the list 
items rather than from an input buffer. 
The converted data is then transferred to 
an output buffer. If all the list items 
have not been converted and transferred 
before the end of the FORMAT statement is 
encountered, control is passed to the 
input/output interface. The input/output 
interface writes (via the WRITE macro 
instruction) the contents of the current 
output buffer onto the output data set. 
The conversion codes starting from the last 
left parenthesis are then repeated for the 
remaining list items. 



If the operation is a write not requir- 
ing a format, the I/O list section proc- 
essing is similar to that described for a 
read not requiring a format. The main dif- 
ference is that the data is obtained from 
the main storage addresses assigned to the 
list items and is then moved to an output 
buffer. In addition, the segment length 
(i.e., the number of bytes in the record 
segment) and a code indicating the position 
of this segment relative to other segments, 
if any, of the logical record are inserted 
in the segment control word. 



CLOSING SECTION ; The compiler generates a 
calling sequence to one of two entry points 
in the closing section of subprogram 
IHCFCOMH each time it encounters the end of 
a READ or WRITE statement in the FORTRAN 
source module. The entry points correspond 
to the operations of read and write, 
requiring or not requiring a format. 



Read/Write Requiring a Format ; If the 
operation is a read requiring a format, the 
closing section simply returns control to 
the load module to continue load module 
execution. If the operation is a write 
requiring a format, the closing section 
branches to the input/output interface. 
The input/output interface writes (via the 
WRITE macro instruction) the contents of 
the current input/output buffer (the final 
record) onto the output data set. The 
input/output interface then returns control 
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to the closing section. The closing sec- 
tion, in turn, returns control to the load 
module to continue load module execution. 



Read/Write Not Requiring a Fo rmat ; If the 
operation is a read not requiring a format, 
the closing section branches to the input/ 
output interface. The input/output inter- 
face reads (via the READ macro instruction) 
successive records until the end of the 
logical record being read is encountered. 
(A FORTRAN logical record consists of all 
the records necessary to contain the I/O 
list items for a WRITE statement not 
requiring a format. ) When the input/output 
interface recognizes the end-of-logical- 
record indicator, control is returned to 
the closing section. The closing section, 
in turn, returns control to the load module 
to continue load module execution. 



If the operation is a write not requir- 
ing a format, the closing section inserts: 
(1) the segment length (i.e., the number of 
bytes in the record segment) and a code 
indicating that this segment is either the 
last or the only segment of the logical 
record into the segment control word of the 
input/output buffer to be written, and (2) 
an end-of- logical-record indicator into the 
last record of the input/output buffer 
being written. The closing section then 
branches to the input/output interface. 
The input/output interface writes (via the 



WRITE macro instruction) the contents of 
this input/output buffer onto the output 
data set. The input/output interface then 
returns control to the closing section. 
The closing section, in turn, returns con- 
trol to the load module to continue load 
module execution. 



Examples of the IH CFC O MH Subprogram 
READ/WRITE Statement Processing Processing 



The following examples illustrate the 
opening section, I/O list section, and 
closing section processing performed by the 
IHCFCOMH subprogram for sequential access 
READ and WRITE statements, requiring or not 
requiring a format. 



Note ; Siibprogram IHCFCOMH processing for 
the direct access READ, FIND, and WRITE 
statements is essentially the same as that 
described for the sequential access READ 
and WRITE statements. The main difference 
is that for direct access statements, sub- 
program IHCFCOMH branches to the direct 
access input/output interface (IHCDIOSE) 
instead of to the sequential access 
input/output interface (IHCFIOSH) . 
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READ REQUIRING A FORMAT; The processing 
performed by subprogram IHCFCGMH for the 
following READ statement and FORMAT state- 
ment is illustrated in Table 32. 



WRIT E REQU IRI N G A FO RMAT ; The processing 
performed by IHCFCOMH for the following 
WRITE statement and FORMAT statement is 
illustrated in Table 33. 



READ (1,2) A, B, C 
2 FORMAT (3F12.6) 



WRITE (3,2) (D(I),,I=1,3) 
2 FORMAT (3F12.6) 



Table 32. 



Opening 
Section 



h 

I/O List 
Section 



Closing 
Section 



IHCFCOMH Processing for a READ 
Requiring a Format 

1. Receives control from load 
module and branches to the 
IHCFIOSH subprogram to 
initialize data set for 
reading. 

2. Passes control to scan por- 
tion of subprogram IHCFCOMH. 

3. Returns control to load 
module. 



1. Receives control from load 
module, converts input data 
for A using subprogram 
IHCFCVTH, and moves con- 
verted data to A. 

2. Returns control to load 
module. 

3. Receives control from load 
module, converts input data 
for B, and moves converted 
data to B. 

4. Returns control to load 
module. 

5. Receives control from load 
module, converts input data 
for C, and moves converted 
data to C. 

6. Returns control to load 
module. 



1. Receives control from load 
module and closes out input/ 
output operation. 

2. Returns control to load 
module to continue load 
module execution. 



Table 33. 



Opening 
Section 



I/O List 
Section 



IHCFCOMH Processing for a WRITE 
Requiring a Format 

1 

1. Receives control from load 
module and branches to sub- 
program IHCFIOSH to initial- 
ize data set for writing. 

2. Passes control to scan por- 
tion of the IHCFCOMH 
subprogram. 

3. Returns control to load 
module. 



1. Receives control from load 
module, converts D(l), and 
moves D(l) to output buffer. 

2. Returns control to load 
module. 

3. Receives control from load 
module, converts D(2), and 
moves D(2) to output buffer. 

4. Returns control to load 
module. 

5. Receives control from load 
module, converts D(3), and 
moves DC 3) to output buffer. 

6. Returns control to load 
module. 



Closing jl. Receives control from load 
Section I module and branches to sub- 
program IHCFIOSH to write 
contents of output buffer. 

Returns control to load 
module to continue load 
module execution. 
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READ NOT REQUIRING A FORMAT: The proc- 
essing performed by IHCFCOMH for the fol- 
lowing READ statement is illustrated in 
Table 34. 



WRITE NOT REQUIRING A FORMAT ; The proc- 
essing performed by IHCFCOMH for the fol- 
lowing WRITE statement is illustrated in 
Table 35. 



READ (5) X;,Y, Z 



WRITE (6) (W(J),J=1,10) 



Table 34. IHCFCOMH Processing for a READ 
Not Requiring a Format 



Table 35. IHCFCOMH Processing for a WRITE 
Not Requiring a Format 



Opening 
Section 



I/O List 
Section 



1. Receives control from load 
module and branches to sub- 
program IHCFIOSH to initial- 
ize data set for reading. 

2. Returns control to load 
module. 



1. 

2. 
3. 

4. 
5. 

6. 
1. 



Receives control from load 
module and moves input data 
to X. 

Returns control to load 
module. 

Receives control from load 
module and moves input data 
to Y. 

Returns control to load 
module. 

Receives control from load 
module and moves input data 
to Z. 

Returns control to load 
module. 



Closing jl. Receives control from load 
Section | module and branches to sub- 
program IHCFIOSH to read 
successive records until the 
end-of- logical-record indi- 
cator is encountered. 

2. Returns control to load 
module to continue load 
module execution. 



Opening 
Section 



I/O List 
Section 



1. Receives control from load 
module and branches to IHC- 
FIOSH to initialize data for 
writing. 

2. Returns control to load 
module. 



1. Receives control from load 
module and moves W(l) to 
output buffer. 

2. Returns control to load 
module. 

3. Receives control from load 
module and moves W(2) to 
output buffer. 

4. Returns control to load 
module. 



5. Receives control from load 
module and moves W(10) to 
output buffer. 

6. Returns control to load 
module. 



Closing j 1. Receives control from load 
Section I module, inserts control 

information, and branches to 
subprogram IHCFIOSH to write 
contents of output buffer, 

2. Returns control to load 
module to continue load 
module execution. 
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READ/WRITE Statement Using NAMELIST 



Included in the calling sequence to the 
IHCNAMEL subprogram^ generated by the com- 
piler when it detects a READ or WRITE 
instruction using a NAMELIST is a pointer 
to the object-time namelist dictionary 
associated with the READ or WRITE. This 
dictionary contains the names and addresses 
of the variables and arrays into which data 
is to be read or from which data is to be 
written. The dictionary also contains the 
information needed to select the conversion 
routine that is to convert the data to be 
placed into the variables or arrays, or to 
be taken from the variables and arrays. 



REA D US ING NAMELIST; The data set contain- 
ing the data to be input to the variables 
or arrays is initialized and successive 
records are read until the one containing 
the namelist name corresponding to that in 
the namelist dictionary is encountered. 
The next record is then read and processed. 

The record is scanned and the first name 
is obtained. The name is compared to the 
variable and array names in the namelist 
dictionary. If the name does not agree, an 
error is signaled and load module execution 
is terminated. If the name is in the dic- 
tionary, processing of the matched variable 
or array is initiated. 

Each initialization constant assigned to 
the variable or an array element is 
obtained from the input record. (One con- 
stant is required for a variable. A number 
of constants equal to the niimber of ele- 
ments in the array is required for an 
array. A constant may be repeated for suc- 
cessive array elements if appropriately 
specified in the input record. ) The appro- 
priate conversion routine is selected 
according to the type of the variable or 
array element. Control is then passed to 
the conversion routine to convert the con- 
stant and to enter it into its associated 
variable or array element. 

The process is repeated for the second 
and subsequent names in the input record. 
When an entire record has been processed, 
the next record is read and processed. 

Processing is terminated upon recogni- 
tion of the SEND record. Control is then 
returned to the calling routine within the 
load module. 



^Subprogram IHCNAMEL is included in the 
load module only if reads and writes using 
NAMELISTs appear in the compiled program. 
Calls are made directly to FRDNL# (for 
READ) or to FWRNL# (for WRITE). 



WRITE USING N AMELIST ; The data set upon 
which the variables and arrays are to be 
written is initialized. The namelist name 
is obtained from the namelist dictionary 
associated with the WRITE, moved to an 
input/output buffer, and written. The 
processing of the variables and arrays is 
then initiated. 

The first variable or array name in the 
dictionary is moved to an input/output 
buffer followed by an equal sign. The 
appropriate conversion routine is selected 
according to the type of the variable or 
array elements. Control is then passed to 
the conversion routine to convert the con- 
tents of the variable or the first array 
element and to enter it into the input/ 
output buffer. A comma is inserted into 
the buffer following the converted quanti- 
ty. If an array is being processed, the 
contents of its second and subsequent ele- 
ments are converted, using the same conver- 
sion routine, and placed into the input/ 
output buffer, separated by commas. When 
all of the array elements have been proc- 
essed or if the item processed was a vari- 
able, the next name in the dictionary is 
obtained. The process is repeated for this 
and subsequent variable or array names. 

If, at any time, the record length is 
exhausted, the current record is written 
and processing resumes in the normal 
fashion. 

When the last variable or array has been 
processed, the contents of the current 
record are written, the characters SEND are 
moved to the buffer and written, and con- 
trol is returned to the calling routine 
within the load module. 



Input/Output Device Manipulation Routines 



The input/output device manipulation 
routines of subprogram IHCFCOMH implement 
the BACKSPACE, REWIND, and ENDFILE source 
statements. These routines receive control 
from within the load module via calling 
sequences that are generated by the compil- 
er when these statements are encountered. 

Note ; The BACKSPACE, REWIND, and ENDFILE 
requests are honored only for sequential 
data sets and are ignored for direct access 
data sets. However, these statements are 
device independent and can be used for 
sequential data sets on either sequential 
or direct access devices. 

The implementation of BACKSPACE, REWIND, 
and ENDFILE statements is straightforward. 
The input/output device manipulation rou- 
tines submit the appropriate control re- 
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quest to subprogram IHCFIOSH, the input/ 
output interface module. After the request 
is executed, control is returned to the 
calling routine within the load module. 



Write-to-Operator Routines 



The write-to-operator routines of sub- 
program IHCFCOMH implement the STOP and 
PAUSE source statements. These routines 
receive control from within the load module 
via calling sequences generated by the com- 
piler upon recognition of the STOP and 
PAUSE statements. 

STOP: A write-to-operator (WTO) macro 
instruction is issued to display the mes- 
sage associated with the STOP statement on 
the console. Load module execution is then 
terminated by passing control to the pro- 
gram termination routine of IHCFCOMH. 

PAUSE : A write-to-operator-with-reply 
(WTOR) macro instruction is issued to dis- 
play the message associated with the PAUSE 
statement on the console and to enable the 
operator's reply to be transmitted. A WAIT 
macro instruction is then issued to deter- 
mine when the operator's reply has been 
transmitted. After the reply has been 
received, control is returned to the call- 
ing routine within the load module. 



Utility Routines 

The utility routines of subprogram 
IHCFCOMH perform the following functions; 

• Process arithmetic-type program 
interruptions . 

• Process specification interruptions. 

• Terminate load module execution. 



PROCESSING OF ERROR MESSAGES ; The error 
message processing routine (IHCERRM) 
receives control from various FORTRAN 
library subprograms when they detect ter- 
minal object-time errors. 

Error message processing consists of 
initializing the data set upon which the 
message is to be written and of writing the 
message and a diagnostic traceback. After 
the traceback is completed for error mes- 
sage IHC218I, control is passed to the 
statement designated in the ERR parameter 



of a FORTRAN READ statement if that para- 
meter was specified. In all other cases, 
control is transferred to a routine that 
will terminate the job. Program interrupts 
will cause a message to be printed, but 
execution will continue. When the extended 
error message facility has been specified, 
execution may continue after the detection 
of an error. 

PROCESSING OF INTERRUPTIONS; The interrupt 
routine (IBFINT) of subprogram IHCFCOMH 
initially receives control from within the 
load module via a compiler-generated call- 
ing sequence. The call is placed at the 
start of the executable coding of the load 
module so that the interrupt routine can 
set up the program interrupt mask. Subse- 
quent entries into the interrupt routine 
are made through specification or 
arithmetic-type interruptions. 

The interrupt routine sets up the pro- 
gram interrupt mask by means of a SPIE 
macro instruction. This instruction speci- 
fies the type of interruptions that are to 
cause control to be passed to the interrupt 
routine, and the location within the rou- 
tine to which control is to be passed if 
the specified interruptions occur. After 
the mask has been set, control is returned 
to the calling routine within the load 
module. 

In processing an interruption, the first 
step taken by the interrupt routine is to 
determine its type. 

A. Arithmetic Interruptions ; If exponen- 
tial overflow or underflow has occurred, 
the appropriate indicators, which are 
referred to by OVERFL (a library subpro- 
gram) , are set. If any type of divide 
check caused the interruption, the indica- 
tor referred to by DVCHK (also a library 
subprogram) is set. 

Regardless of the type of interruption 
that caused control to be given to the 
interrupt routine, the old program PSW is 
written out for diagnostic purposes. 

After the interruption has been proc- 
essed, control is returned to the inter- 
rupted routine at the point of 
interruption. 

B, Specification Interruption s; If an 

interrupt is caused by a specification 
exception and the boundary alignment option 
was specified by the user during system 
generation, the boundary adjustment routine 
(IHCADJST) is loaded from the link library 
(SYSl.LINKLIB). 

This routine determines whether or not 
the interruption was caused by an instruc- 
tion that referred to improperly aligned 
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data. If it was not,, the routine causes 
abnormal termination of the load module. 
If it was, the routine: 

1. Causes message IHC210I, which contains 
the main program PSW, to be generated. 

2. Moves the misaligned data to a proper- 
ly aligned boundary. 

3. Re-executes the instruction that 
refers to the data. 

If no interruption occurs when the 
instruction is re-executed, the data is 
moved back to its original location. If 
there is a new condition code, it is placed 
in the PSW of the Program Interruption Ele- 
ment (PIE). The boundary adjustment rou- 
tine then returns control to the control 
program, which loads the PSW of the PIE to 
effect a return to the interrupted program. 

If a divide check, exponential overflow 
or underflow interruption occurs when the 
instruction is re-executed, the interrup- 
tion will be handled as described in 
"Arithmetic Interruptions. " 

If a data, protection, or addressing 
interruption occurs when the instruction is 
re- executed, the boundary adjustment rou- 
tine generates the message IHC210I. The 
PSW information in this message gives the 
cause of the interruption and the location 
of the instruction in the main program that 
caused the interruption. Then, since proc- 
essing cannot continue, the routine issues 
a SPIE macro instruction to remove specifi- 
cation interruptions from those interrup- 
tions handled by this routine and re- 
executes the instruction. This causes 
abnormal termination of the load module 
because of the original specification 
error. 



P ROGRAM TERMINATION ; The load module ter- 
mination routine (IBEXIT) of the IHCFCOMH 
subprogram receives control from various 
library subprograms (e.g., DUMP and EXIT) 
and from other IHCFCOMH routines (e.g., the 
routine that processes the STOP statement) . 

This routine terminates execution of the 
load module by the following means: 

• Calling the appropriate input/output 
interface(s) to check (via the CHECK 
macro instruction) outstanding write 
requests. 

• Issuing a SPIE macro instruction with 
no parameters indicating that the 
FORTRAN object module no longer desires 
to give special treatment to program 
interruptions and does not want mask- 
able interruptions to occur. 



Returning to the operating system 
supervisor. 



CONVERSION ROUTINES (IHCFCVTH) 



The conversion routines (see Table 39) 
either convert data to be placed into the 
I/O list items or convert data to be taken 
from the I/O list items. 

These routines receive control either 
from the I/O list section of subprogram 
IHCFCOMH during its processing of list 
items for READ/WRITE statements requiring a 
format, from the routines that process 
READ/WRITE Statements using a NAMELIST, or 
from the DUMP and PDUMP subprograms. 

Each conversion routine is associated 
with a conversion type format code and/or a 
type. If an I/O list item for a READ/WRITE 
statement requiring a format is being proc- 
essed, the conversion routine is selected 
according to the conversion type format 
code that is to be applied to the list 
item. If a list item for a READ/WRITE 
using a NAMELIST is being processed, the 
conversion routine is selected according to 
the type of the list item. 

If a READ statement is being imple- 
mented, the conversion routine obtains data 
from the input/output buffer, converts it 
according to its associated conversion type 
format code or type, and enters the con- 
verted data into the list item. The proc- 
ess is reversed if a WRITE statement is 
being implemented. 

For the DUMP and PDUMP subprograms, the 
format code parameter passed to them deter- , 
mines the selection of the output conver- 
sion routine to be used to place the output 
in the desired form. 



IHCFIOSH 



Subprogram IHCFIOSH, the object-time 
FORTRAN sequential access input/output data 
management interface, receives input/output 
requests from the IHCFCOMH subprogram and 
submits them to the appropriate BSAM (basic 
sequential access method) routines and/or 
OPEN and CLOSE routines for execution. 

When the extended error message facility 
has been specified at system generation 
time, subprogram IHCFIOSH will include pro- 
gramming to allow execution to continue 
after an error occurs. 
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Chart 26 illustrates the overall logic 
and the relationship among the routines of 
the IHCFIOSH subprogram. Table 38, the 
IHCFIOSH routine directory, lists the rou- 
tines used in subprogram IHCFIOSH and their 
functions. 



BLOCKS AND TABLES USED 



obtained by the IHCFIOSH subprogram via the 
GETMAIN macro instruction. The addresses 
of the unit blocks are placed in the unit 
assignment table as the unit blocks are 
constructed. All subsequent references to 
the unit numbers are then made through the 
unit assignment table. Figure 57 illus- 
trates the format of a unit block for a 
unit that is defined as a sequential access 
data set. 



The IHCFIOSH subprogram uses the follow- 
ing blocks and table during its processing 
of sequential access input/output requests: 
(1) unit blocks, and (2) unit assignment 
table. The unit blocks are used to indi- 
cate input/output activity for each unit 
ntimber (i.e., data set reference number) 
and to indicate the type of operation 
requested. In addition, the unit blocks 
contain skeletons of the data event control 
blocks (DECB) and the data control blocks 
(DCB) that are required for input/output 
operations. The unit assignment table is 
used as an index to the unit blocks. 



Each unit block is divided into four 
sections: a housekeeping section, two DECB 
skeleton sections, and a DCB skeleton 
section. 

Housekeeping Section : The housekeeping 
section is maintained by the IHCFIOSH sub- 
program. The section is maintained by IHC- 
FIOSH. The information contained in it 
indicates the data set type, records input/ 
output buffer locations, and records 
addresses internal to the input/output buf- 
fers so that blocked records may be proc- 
essed. The fields of this section are: 



Unit Blocks 



The first reference to each unit number 
(data set reference number) by an input/ 
output operation within the FORTRAN load 
module causes subprogram IHCFIOSH to con- 
struct a unit block for each unit number. 
The main storage for the unit blocks is 



• ABYTE . This field, containing the data 
set type passed to subprogram IHCFIOSH 
by the IHCFCOMH following can be set to 
one of the following: 

FO — Input data set which is 

formatted. 
FF — Output data set which is 

formatted. 



J. ^ ^ y ^ ^ 

1 ABYTE 1 BBYTE | CBYTE | DBYTE | U bytes | 
L _ L _X L L_ _ i 


r — * — * ^ — -T — 1 

1 Address of Buffer 1 | 4 bytes | 
j. + ^ 

] Address of Buffer 2 | U bytes | 

1. _ , _^ 1 1 


r T T 

] Current buffer pointer (Note) | U bytes ] 

L _ _ J. _ _ _J 


r — — — T 1 

1 Record offset (RECPTR) (Note) | 4 bytes | 

I 1 J 


r — r — — -1 

] Address of last DECB | 4 bytes | 
L_ __ ___ _ x_ 1 


r _- ____^_ _^ 
j Mask for alternating buffers | 4 bytes | 

L _ „ L _J 


r ~ r — — 1 

1 DECBl skeleton section | 20 bytes | 

L_„ __ __ L _ _J 


1 Not used 1 LIVECNTl | 4 bytes | 

L _ _ .^ L L J 


r — — r 1 

1 DECB2 skeleton section | 20 bytes | 

L _ _ _^^ _ _ _ _ , L J 


r — T - - - - — T 1- — i 

1 Work space | Not used | LIVECNT2 | 4 bytes \ 

I ^ i „ X —J. _ i 


r — — --I. -^ -^ 
1 DCB skeleton section | 88 bytes | 



Housekeeping 
Section 



Note: Used only for 
variable -length 
and/or blocked 
records 



Figure 57. Format of a Unit Block for a Sequential Access Data Set 
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00 — Input data set which is not 

formatted. 
OF — Output data set which is not 

formatted. 



o BBYTE . This field contains bits that 
are set and examined by IHCFIOSH during 
its processing. The bits and their 
meanings when on are, as follows: 

— exit to subroutine IHCFCOMH on 

input/output error 

1 — input/output error occurred 

2 — current buffer indicator 

3 — not used 

4 — end-of-current buffer indicator 

5 — blocked data set indicator 

6 — variable record format switch 

7 — not used 



« CBYTE . This field also contains bits 
that are set and examined by subroutine 
IHCFIOSH. The bits and their meanings 
when on are, as follows: 



— 

1 — 

2 — 

3 — 

4 — 

5 — 

6 — 

7 — 



data control block opened 

data control block not TCLOSEd 

data control block not previously 

opened 

buffer pool attached 

data set not previously rewound 

not used 

concatenation occurring; reissue 

READ 

data set is DUMMY 



'» D BYT E. This field contains bits that 
are set and examined by IHCFIOSH during 
the processing of an Input/Output 
operation involving a backspace re- 
quest. The bits and their meanings, 
when on, are as follows : 

— a physical backspace has occurred 

1 — previous operation was BACKSPACE 

2 — not used 

3 — end-of-file routine should retain 

buffers 

4 — not used 

5 — not used 

6 — END FILE followed by BACKSPACE 

7 — not used 

• Address of Buffer 1 and Address of 
Buffer 2 . These fields contain point- 
ers to the two input/output buffers 
obtained during the opening of the data 
control block for this data set. 

• Current Buffer Pointer . This field 
contains a pointer to the input/output 
buffer currently being used. 

• Record Offset (RECPTR) . This field 
contains a pointer to the current 



logical record within the current 
buffer. 

• Address of Last DECB. This field con- 
tains a pointer to the DECB last used. 

• Mask for Alternating Buffers . This 
field contains the bits which enable an 
Exclusive Or operation to alternate the 
current buffer pointer. 

DECB SKELETON SECTIONS (DECBl AND DECB2) : 
The DECB (data event control block) skele- 
ton sections are blocks of main storage 
within the unit block. They have the same 
format as the DECB constructed by the con- 
trol program for an L format of an S-type 
READ or WRITE macro instruction (see the 
publication IBM Svstem/360 Operating Sys- 
te m; Supervisor and Data Management Macro 
Instructions , Form C28-6647). The various 
fields of the DECB skeleton are filled in 
by subprogram IHCFIOSH; the completed block 
is referred to when IHCFIOSH issues a read/ 
write request to BSAM. The read/write 
field is filled in at open time. For each 
input/output operation, IHCFIOSH supplies 
subprogram IHCFCOMH with: (1) an indica- 
tion of the type of operation (read or 
write), and (2) the length of and a pointer 
to the input/output buffer to be used for 
the operation. 

• LIVECNTl and LIVECNT 2. These fields 
indicate whether any input/output 
operation performed for the data set is 
unchecked. (A value of 1 indicates 
that a previous read or write has not 
been checked; a value of indicates 
that all previous read and write opera- 
tions for the data set have been 
checked. ) 

• Work Space . This field is used to 
align the logical record length of a 
variable record segment on a full word 
boundary. 



DCB SKELETON SECTION: 



The DCB (data con- 
skeleton section is a block of 

It is 



trol block) 

main storage within the unit block. 

of the same format as the DCB constructed 

by the control program for a DCB macro 

instruction under BSAM (see the publication 

IBM Sy stem/360 Operating System: Su^ervi- 

sor and Data Management Macro Instruc- 
tions ) . The various fields of the DCB 
skeleton are filled in by the control pro- 
gram when the DCB for the data set is 
opened (see the publication IBM System/360 

Operating System: Concepts and 

Fa cili ties) . 

Note ; Standard default values may also be 
inserted in the DCB skeleton by the 
IHCFIOSH subprogram. See "Unit Assignment 
Table" for a discussion of when default 
values are inserted into the DCB skeleton. 
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Unit Agsiqnment Table 



The unit assignment table (IHCUATBL) 
resides in the FORTRAN system library 
(SYSl. FORTLIB) . Its size depends on the 
maximum number of units that can be 
referred to during execution of any FORTRAN 
load module. This number (< 99) is speci- 
fied by the user during the system genera- 
tion process via the FORTLIB macro 
instruction. 



The unit assignment table is designed to 
be used by both the IHCFIOSH and IHCDIOSE 
subprograms. It is included once, by the 
linkage editor, in the FORTRAN load module 
as a result of an external reference to it 
within IHCFIOSH and/or IHCDIOSE . 



The unit assignment table contains a 
16-byte entry for each of the unit numbers 
that can be referred to by the user. These 
entries differ iti format depending on 
whether the unit has been defined as a 
sequential access or a direct access data 
set. 



Figure 58 illustrates the format of the 
unit assignment table. 



Because subprogram IHCFIOSH deals only 
with sequential access data sets, the 
remainder of the discussion on the unit 
assignment table is devoted to unit assign- 
ment table entries for sequential access 
data sets. If the IHCFIOSH subprogram 
encounters a reference to a direct access 
data set, it is considered an error, and 
control is passed to the load module ter- 
mination routine of the IHCFCOMH 
subprogram. 



The pointers to the unit blocks created 
for sequential data sets are inserted into 
the unit assignment table entries by sub- 
program IHCFIOSH when the unit blocks are 
constructed. 



Note: Default values are standard values 
that IHCFIOSH inserts into the appropriate 
fields (e.g., BUFNO) of the DCB skeleton 
section of the unit blocks if the user does 
either of the following: 

• Causes the load module to be executed 
via a cataloged procedure. 

• Fails, in stating his own procedure for 
execution, to include in the DCB param- 
eter of his DD statements those sub- 
parameters (e.g., BUFNO) that he is 



Unit number (DSRN) | ^ | 
being used for current} | 
operation | n x 16 | 4 bytes 
^ ^ j..^ 4 

ERRMSG 1 READ | PRINT | PUNCH j 
DSRN2 1 DSRN3 | DSRN^ | DSRN^ |4 bytes 
X J X 4 

UBLOCKOl field |U bytes 
4 

DSRNOl default values |8 bytes 

J. 


LISTOl field |U bytes 
_ J. 


_ ^ 

1 . 

1 

1 - 

1 

1 . 

_ J. _ 


— — _ ^ _ 

UBLOCKn fields ^^ bytes 
4 

DSRNn default values'' | 8 bytes 

_ J. 


_ — _ _ ^ 

LISTn fields |U bytes 



f 4 ^ 

^n is the maximum number of units that 
can be referred to by the FORTRAN load 
module. The size of the unit table is 
equal to (8 + n x 16) bytes. 

2 Unit number (DSRN) of error output 
device. 

^Unit number (DSRN) of input device for a 
read of the form: READ b, list . 

**Unit number (DSRN) of output device for 
a print operation of the form: PRINT 
b, list. 

^Unit number (DSRN) of output device for 
a punch operation of the form: PUNCH 
b, list . 

6The UBLOCKn field contains either a 
pointer to the unit block constructed 
for unit number n if the unit is being 
used at object time, or a value of 1 if 
the unit is not being used, 

■'The default values for the various unit 
numbers are specified by the user and 
are assembled into the unit assignment 
table entries during the system genera- 
tion process. The default values are 
used only by subprogram IHCFIOSH; they 
are ignored by the IHCDIOSE subprogram. 

^If the unit is defined as a direct 
access data set, the LISTn field con- 
tains a pointer to the parameter list 
that defines the direct access data set. 
Otherwise, this field contains a value 
of 1. 

Figure 58. Unit Assignment Table Format 



permitted to include (see the publication 
IBM System/360 Operating System; FORTRAN 
IV (G and H) Programmer' s Guide ) . 
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Control is returned to subprogram IHC- 
FIOSH during data control block opening so 
that it can determine whether or not the 
user has included the subparameters in the 
DCB parameter of his DD statements. Sub- 
program to IHCFIOSH examines the DCB skele- 
ton fields corresponding to user-permitted 
subparameters and, upon encountering a null 
field (indicating that the user has not 
specified the subparameter) , inserts the 
standard value (i.e., the default value) 
for the subparameter into the DCB skeleton. 
(If the user has included these subparame- 
ters in his DD statement, the control pro- 
gram routine performing data control block 
opening inserts the subparameter values, 
before transferring control to the IHC- 
FIOSH, subprogram into the DCB skeleton 
fields reserved for those values. ) 



BUFFERING 



All input/output operations are double 
buffered. (The double buffering scheme can 
be overridden by the user if he specifies 
in a DD statement: BUFN0=1. ) This implies 
that during data control block opening, two 
buffers will be obtained. The addresses of 
these buffers are given alternately to the 
IHCFCOMH subprogram as pointers to: 

• Buffers to be filled (in the case of 
output ) . 

• Information that has been read in and 
is to be processed (in the case of 
input) . 



COMMUNICATION WITH THE CONTROL PROGRAM 



In requesting services of the control 
program, subprogram IHCFIOSH uses L and E 
forms of S-type macro instructions (see the 
publication IBM System/360 Operating Sys- 
tem: Supervisor and Data Management Macro 
Instructions ) . 



OPERATION 



The processing of subprogram IHCFIOSH is 
divided into five sections : initializa- 
tion, read, write, device manipulation, and 
closing. When called by the IHCFCOMH sub- 
program, a section of subprogram IHCFIOSH 
performs its function and then returns con- 
trol to IHCFCOMH. 



Initialization 



The initialization action taken by sub- 
program IHCFIOSH depends upon the nature of 
the previous input/output operation 
requested for the data set. The previous 
operation possibilities are: 

• No previous operation. 

• Previous operation read or write. 

• Previous operation backspace. 

• Previous operation write end-of-data 
set. 

• Previous operation rewind. 

NO PREVIOUS OPERATION : If no previous 
operation has been performed on the unit 
specified in the input/output request, the 
initialization section generates a unit 
block for the unit number. The data set to 
be created is then opened (if the current 
operation is not rewind or backspace) via 
the OPEN macro instruction. The addresses 
of the input/output buffers, which are 
obtained during the opening process and 
placed into the DCB skeleton, are placed 
into the appropriate fields of the house- 
keeping section of the unit block. The 
DECB skeleton is then set to reflect the 
nature of the operation (read or write) , 
the format of the records to be read or 
written, and the address of the input/ 
output buffer to be used in the operation. 

If the requested operation is a write, a 
pointer to the buffer position, at which 
subprogram IHCFCOMH is to place the record 
to be written, and the block size or logic- 
al record length (to accommodate blocked 
logical records) are placed into registers, 
and control is returned to the IHCFCOMH 
subprogram. 

If the requested operation is a read, a 
record is read, via a READ macro instruc- 
tion, into the input/output buffer, and the 
operation is checked for completion via the 
CHECK macro instruction. A pointer to the 
location of the record within the buffer, 
along with the number of bytes read or the 
logical record length, are placed into 
registers, and control is returned to the 
IHCFCOMH sxibprogram. 

Note: During the opening process, control 
is returned to the IHCDCBXE routine in sub- 
program IHCFIOSH. This routine determines 
whether or not the data set being opened is 
a 1403 printer. If it is, the RECFM field 
in the DCB for the data set is altered to 
machine carriage control (FM). In addi- 
tion, a pointer to the unit block generated 
for the printer, and the physical address 
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of the printer are placed into a control 
block area (CTLBLK) for the printer within 
the IHCFIOSH subprogram. The CTLBLK also 
contains a third print buffer. This buffer 
is used in conjunction with the two buffers 
already obtained for the printer. 

Figure 59 illustrates the format of the 
CTLBLK. 



CTLBLK i a (BUF 3) 

^ 

I a (unit block) 

h T 

|a(printer) (record length 

|. X 

JFTOO^ 

|. 

jFOOli 

L 



BUF3 



(third print buffer 

.JL 



4 bytes i 
— i 



U bytes J 
^ 

U bytes I 



I ^Used in the task input/output table 
( (TIOT) search. 

L . ^. 

Figure 59. CTLBLK Format 



H bytes ( 
-1 

^ bytes I 
J 

14 U bytes I 

-H 
I 



PREVIOUS OPERATION READ OR WRITE; If the 
previous operation performed on the unit 
specified in the present input/output re- 
quest was either a read or write, the 
initialization section determines" the 
nature of the present input/output request. 
If it is a write, a pointer to the buffer 
position, at which subprogram IHCFCOMH is 
to place the record to be written, and the 
block size or logical record length are 
placed into registers, and control is 
returned to the IHCFCOMH subprogram. 

If the operation to be performed is a 
read, a pointer to the buffer location of 
the record to be processed, along with the 
number of bytes read or logical record 
length, are placed into registers, and con- 
trol is returned to subprogram IHCFCOMH. 

PREVIOUS OPERATION BACKSPACE; If the pre- 
vious operation performed on the unit spe- 
cified in the present input/output request 
was a backspace, the initialization section 
determines the type of the present opera- 
tion (read or write) and modifies the DECB 
skeleton, if necessary, to reflect the 
operation type. (If the operation type is 
the same as that of the operation that pre- 
ceded the backspace request, the DECB 
skeleton need not be modified. ) S\ibsequent 
processing steps are the same as those 
described for "No Previous Operation," 
starting at the point after tbe DECB skele- 
ton is set to reflect operation type. 



PREVIOUS „ OPERATION WRITE END-OF-DATA SET : 
If the previous operation performed on the 
\anit specified in the present input/output 
request was a write end-of-data set, a new 
data set using the same unit number is to 
be created. In this case, the initializa- 
tion section closes the data set. Then, in 
order to establish a correspondence between 
the new data set and the DD statement 
describing that data set, subprogram IHC- 
FIOSH increments the unit sequence number 
of the ddname. (The ddname is placed into 
the appropriate field of the DCB skeleton 
prior to the opening of the initial data 
set associated with the unit number. ) Dur- 
ing the opening of the data set, the ddname 
will be used to merge with the appropriate 
DD statement. The data set is then opened. 
Subsequent processing steps are the same as 
those described for "No Previous Opera- 
tion, " starting at the point after the data 
set is opened. 

PREVIOUS OPERATION REWIND; If the previous 
operation performed on the unit specified 
in the present input/output request was a 
rewind, the ddname is initialized (set to 
FTxxFOOl) in order to establish a corres- 
pondence between the initial data set asso- 
ciated with the unit number and the DD 
statement describing that data set. The 
data set is then opened. Subsequent 
processing steps are the same as those 
described for "No Previous Operation, " 
starting at the point after the data set is 
opened. 



Read 



The read section of subprogram IHCFIOSH 
performs two functions: (1) reads physical 
records into the buffers obtained during 
data set opening, and (2) makes the con- 
tents of these buffers available to the 
IHCFCOMH subprogram for processing. 

If the records being processed are 
blocked, the read section does not read a 
physical record each time it is given con- 
trol. Subprogram IHCFIOSH only reads a 
physical record when all of the logical 
records of the blocked record under consid- 
eration have been processed by the IHCFCOMH 
subprogram. However, if the records being 
processed are either unblocked or of U- 
format, the read section of subprogram IHC- 
FIOSH issues a READ macro instruction each 
time it receives control. 

The reading of records by this section 
is overlapped. That is, while the contents 
of one buffer are being processed, a physi- 
cal record is being read into the other 
buffer. When the contents of one buffer 
have been processed, the read into the 
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other buffer is checked for completion. 
Upon completion of the read operation, 
processing of that buffer's contents is 
initiated. In addition, a read into the 
second buffer is initiated. 

Each time the read section is given con- 
trol, it makes the next record available to 
subprogram IHCFCOMH for processing. (In 
the case of blocked records, the record 
presented to IHCFCOMH is logical. ) The 
read section of IHCFIOSH places: (1) a 
pointer to the record's location in the 
current input/output buffer and (2) the 
number of bytes read or logical record 
length into registers, and then returns 
control to the IHCFCOMH subprogram. 



riage control character is changed to 
machine code, and three buffers, instead of 
the normal two, are used when writing on 
the printer. 

ERROR PROCESSING WITHOUT EXTENDED ERROR 
MESSAGE FACILITY ; An error number is put 
into a parameter list and register 13 is 
set up to point to a save area in IBCOM, 
The user* s save area is linked to this save 
area. The error monitor is then called to 
print a message on the object error unit. 

ERROR PROCESSING WITH EXTENDED ERROR MES- 
SAGE FACILITY ; A common subroutine is 
called to prepare for a call to the error 
monitor. The common subroutine; 



Write 



The write section of subprogram IHCFIOSH 
performs two functions; (1) writes physi- 
cal records and (2) provides IHCFCOMH with 
buffer space in which to place the records 
to be written. 

If the records being written are 
blocked, the write section does not write a 
physical record each time it is given con- 
trol. Subprogram IHCFIOSH only writes a 
physical record when all of the logical 
records that make up the blocked record 
under consideration have been placed into 
the input/output buffer by the IHCFCOMH 
subprogram. However, if the records being 
written are either unblocked or of subpro- 
gram U-format, the write section of subpro- 
gram IHCFIOSH issues a WRITE macro instruc- 
tion each time it receives control. 

The writing of records by this section 
is overlapped. That is, while subprogram 
IHCFCOMH is filling one buffer, the con- 
tents of the other buffer are laeing writ- 
ten. When an entire buffer has been 
filled, the write from the other buffer is 
checked for completion. Upon completion of 
the write operation, subprogram IHCFCOMH 
starts placing records into that buffer. 
In addition, a write from the second buffer 
is initiated. 

Each time control is transferred to the 
write section, it provides subprogram IHCF- 
COMH with buffer space in which to place 
the record to be written. The IHCFIOSH 
subprogram places: (1) a pointer to the 
location within the current buffer at which 
IHCFCOMH is to place the record, and (2) 
the block size or logical record length 
into registers, and then returns control to 
IHCFCOMH. 

Not e ; The write section checks to see 
whether or not the data set being written 
on is a 1403 printer. If it is, the car- 



1. converts the data set reference and 
puts it into the last four bytes of 
the message 

2. links save areas as described when no 
error message facility has been 
specified 

3. calls the error monitor (IHCERRM) 



The error monitor may return to continue 
execution. 

For error conditions 214, 217, 218, 219, 
220, and 231 if user corrective action is 
taken, and for error 214 if the operation 
was input, the remainder of the I/O list is 
ignored upon return from the common subrou- 
tine. For error condition 214 under any 
other condition, the record format is 
changed to V and execution continues. 

For any error condition except 214 and 
217, upon return from the error monitor, 
IHCFIOSH returns an indication that an 
error has occurred to the caller. 

In the case of an end-of-data set, sub- 
program IHCFIOSH simply passes control to 
the end-of-data set routine of the IHCFCOMH 
subprogram. 

Chart 27 illustrates the execution-time 
input/output recovery procedure for any 
input/output errors detected by the input/ 
output supervisor. 



Device Manipulati on 

The device manipulation section of sub- 
program IHCFIOSH processes backspace, 
rewind, and write end-of-data set requests, 

BACKSPACE ; IHCFIOSH processes the back- 
space request by issuing the appropriate 
number of BSP (physical backspace) macro 
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instructions (0, 1, 2 or 3) and adjusting 
the RECPTR in the unit block to point to 
the preceding logical record. The number 
of BSP's issued will depend on the number 
of buffers used, the previous Input/Gutput 
operation, and the position of RECPTR prior 
to the backspace. 

For unformatted records, the processing 
of a backspace request also includes 
examining the SDW (Segment Descriptor Word) 
of each record segment in order to locate 
the first segment of a spanned record 
(i.e., a logical record which causes more 
than one physical Input/Output operation to 
be performed). Control is then returned to 
IHCFCOMH. 

REWIND ; Subprogram IHCFIOSH processes the 
rewind request by issuing a CLOSE macro 
instruction, using the REREAD option « This 
option has the same effect as a rewind. 
Control is then returned to IHCFCOMHo 



to the BDAM routines. The BSAM routines 
format and create a new data set consisting 
of blank records. ) 



The IHCDIOSE subprogram receives control 
from: (1) the initialization section of 
the FORTRAN load module if a DEFINE FILE 
statement is included in the source module, 
and (2) IHCFCOMH whenever a READ, WRITE, or 
FIND direct access statement is encountered 
in the load module. 

Charts 28 and 29 illustrate the overall 
logic and the relationship among the rou- 
tines of the IHCDIOSE subprogram. Table 
39, the IHCDIOSE routine directory, lists 
the routines used in IHCDIOSE and their 
functions. 



WRITE END-OF-DATA SET ; Subprogram IHCFIOSH 
processes this request by issuing a CLOSE 
macro instruction, type = T. It then frees 
the input/output buffers by issuing a FREE- 
POOL macro instruction, and returns control 
to the IHCFCOMH subprogram. 



Closing 



The closing section of subprogram IHC- 
FIOSH examines the entries in the vmit 
assignment table to determine which data 
control blocks are open. In addition, this 
section ensures that all write operations 
for a data set are completed before the 
data control block for that data set is 
closed. This is done by issuing a CHECK 
macro instruction for all double-buffered 
output data sets. Control is then returned 
to the IHCFCOMH subprogram. 

Note; If a m03 printer is being used, a 
write from the last print buffer is issued 
to insure that the last line of output is 
written. 



IHCDIOSE 



Subprogram IHCDIOSE , the object- time 
FORTRAN direct access input/output data 
management interface, receives input/output 
requests from the IHCFCOMH subprogram and 
submits them to the appropriate BDAM (basic 
direct access method) routines and/or open 
and close routines for execution. (For the 
first input/output request involving a non- 
existent data set, the appropriate BSAM 
routines must be executed prior to linking 



BLOCKS AND TABLE USED 



Subprogram IHCDIOSE uses the following 
blocks and table during its processing of 
direct access input/output requests: 
(1) \init blocks, and (2) unit assignment 
table. The unit blocks are used to ind- 
icate input/output activity for each unit 
number (i.e., data set reference number) 
and to indicate the type of operation 
requested. In addition, each unit block 
contains skeletons of the data event con- 
trol blocks (DECB) and the data control 
block (DCB) that are required for input/ 
output operations. The unit assignment 
table is used as an index to the unit 
blocks. 



Unit Blocks 



The first reference to each unit number 
(i.e., data set reference number) by a 
direct access input/output operation within 
the FORTRAN load module causes subprogram 
IHCDIOSE to construct a unit block for each 
of the referenced unit numbers. The main 
storage for the unit blocks is obtained by 
the IHCDIOSE subprogram via the GETMAIN 
macro instruction. The addresses of the 
unit blocks are inserted into the corres- 
ponding unit assignment table entries as 
the unit blocks are constructed. Subse- 
quent references to the unit numbers are 
then made through the unit assignment 
table. 

Figure 60 illustrates the format of a 
unit block for a unit that has been defined 
as a direct access data set. 
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Figure 60. 



Format of a Unit Block for a 
Direct Access Data Set 



11 - L format specified in DEFINE 
FILE statement 

6-7 -- not used 

Note: Subprogram IHCDIOSE refers only to 
bits 1, 2, and 3. 



RECNUM: This field contains the number of 
records in the data set as specified in the 
parameter list for the data set in a DEFINE 
FILE statement. It is filled in by the 
file initialization section after the data 
control block for the data set is opened. 



S TATUS A ; This field specifies the status 
of the buffer currently being used. The 
bits and their meanings when on are, as 
follows: 



The meanings of the various unit block 
fields are outlined below. 



— READ macro instruction has been 
issued 



1 — WRITE macro instruction has been 
issued 



lOTYPE ; This field, containing the data 
set type passed to subprogram IHCDIOSE by 
the IHCFCOMH subprogram, can be set to one 
of the following: 

FO — input data set requiring a format 

FF — output data set requiring a 
format 

00 — input data set not requiring a 
format 

OF -- output data set not requiring a 
format 



STATUSU : This field specifies the status 
of the associated unit number. The bits 
and their meanings when on are, as follows: 

— data control block for data set 

is open for BSAM 

1 — error occurred 

2 — two buffers are being used 

3 — data control block for data set 

is open for EDAM 

4-5 — 10 - U format specified in DEFINE 
FILE statement 

01 - E format specified in DEFINE 
FILE statement 



2 — CHECK macro instruction has been 
issued 



3-7 -- Not used 



CURBUF : This field contains the address of 
the DECB skeleton currently being used. It 
is initialized to contain the address of 
the DECBA skeleton by the file initializa- 
tion section of IHCDIOSE after the data 
control block for the data set is opened. 



BLKR EFA : This field contains an integer 
that indicates either the relative position 
within the data set of the record to be 
read, or the relative position within the 
data set at which the record is to be writ- 
ten. It is filled in by either the read or 
write section of subprogram IHCDIOSE prior 
to any reading or writing. In addition, 
the address of this field is inserted into 
the DECBA skeleton by the file initializa- 
tion section of IHCDIOSE after the data 
control block for the data set is opened. 



STAT USB : This field specifies the status 
of the next buffer to be used if two buf- 
fers are obtained for this data set during 
data control block opening. The bits and 
their meanings are the same as described 
for the STATUSA field. However, if only 
one buffer is obtained during data control 
block opening, this field is not used. 
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N XTBU F ; This field contains the address of 
the DECB skeleton to be used next if two 
buffers are obtained during data control 
block opening. It is initialized to con- 
tain the address of the DECBB skeleton by 
the file initialization section of subpro- 
gram IHCDIOSE after the data control block 
for the data set is opened. However, if 
only one buffer is obtained during data 
control block opening, this field is not 
used. 



BLKREFB ; The contents of this field are 
the same as described for the BLKREFA 
field. It is filled in either by the read 
or the write section of subprogram IHCDIOSE 
prior to any reading or writing. In addi- 
tion, the address of this field is inserted 
into the DECBB skeleton by the file initia- 
lization section of IHCDIOSE after the data 
control block for the data set is opened. 
However, if only one buffer is obtained 
during data control block opening, this 
field is not used. 



DECBA S KELETON; This field contains the 
DECB (data event control block) skeleton to 
be used when reading into or writing from 
the current buffer. It is of the same form 
as the DECB constructed by the control pro- 
gram for an L form of an S-type READ or 
WRITE macro instruction under BDAM (see the 
publication IBM System/3 60 Op era ting Sys- 
tem; Sup erv iso r and Data Management Macro 
Instructions) . 



The various fields of the DECBA skeleton 
are filled in by the file initialization 
section of subprogram IHCDIOSE after the 
data control block for the data set is 
opened. The completed DECB is referred to 
when IHCDIOSE issues a read or a write 
request to BDAM. For each input/output 
operation, IHCDIOSE supplies IHCFCOMH with 
the address of and the size of the buffer 
to be used for the operation. 



DECBB SKELETON ; The DECBB skeleton is used 
when reading into or writing from the next 
buffer. Its contents are the same as 
described for the DECBA skeleton. The 
DECBB skeleton is completed in the same 
manner as described for the DECBA skeleton. 
However, if only one buffer is obtained 
during data control block opening, this 
field is not used. 



DCB SKELETON ; This field contains the DCB 
(data control block) skeleton for the asso- 
ciated data set. It is of the same format 
as the DCB constructed by the control pro- 
gram for a DCB macro instruction under BDAM 
(see the publication IBM System/360 Operat- 



ing System; Supervisor and Data Management 
Macro Instructions) . 



The various fields of the DCB skeleton 
are filled in by the control program when 
the DCB for the data set is opened (see the 
publication IBM Svste m /360 Operating Sys- 
tem; C oncepts an d Faci lit ies ) . 



Unit Assignment Table 



The unit assignment table (IHCUATBL) 
resides on the FORTRAN system library 
(SYSl.FORTLIB) . Its size depends on the 
maximum number of units that can be 
referred to during execution of any FORTRAN 
load module. This number (<99) is speci- 
fied by the user during the system genera- 
tion process via the FORTLIB macro 
instruction. 



The unit assignment table is designed to 
be used by both the IHCFIOSH and IHCDIOSE 
subprograms. It is included once, by the 
linkage editor, in the FORTRAN load module 
as a result of an external reference to it 
within IHCFIOSH and/or IHCDIOSE . 



The unit assignment table contains a 
16-byte entry for each of the unit numbers 
that can be referred to by either subpro- 
gram IHCDIOSE or IHCFIOSH. These entries 
differ in format depending on whether the 
unit has been defined as a direct access or 
as a sequential access data set. Because 
subprogram IHCDIOSE deals only with direct 
access data sets, only the entry for a 
direct access unit is shown here. (For the 
format of the unit assignment table as a 
whole, see "Table and Blocks Used" under 
"IHCFIOSH"). If subprogram IHCDIOSE 
encounters a reference to a sequential 
access data set, it is considered an error, 
and control is passed to the load module 
teinnination routine of the IHCFCOMH 
subprogram. 



Figure 61 illustrates the unit assign- 
ment table entry format for a direct access 
data set. 



The pointers to the unit blocks are 
inserted into the unit assignment table 
entries by subprogram IHCDIOSE when the 
\init blocks are constructed. 



The pointers to the unit blocks are 
inserted into the unit assignment table 
entries by subprogram IHCDIOSE when the 
unit blocks are constructed. 
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f— 



Pointer to unit block xx 
(UBLOCKxx) 



T 1 

4 bytes 



Default values for DSRNxx (ap- 
plies only to sequential access 
data sets — not used by sub- 
program IHCDIOSE ) 



Pointer to parameter list xx 
CLISTxx) 



8 bytes 



4 bytes 



UBLOCKxx is the unit block generated 
for unit number xx. 

DSRNxx is the unit number for the 
direct access data set (xx<99). 

IiISTxx is the parameter list that 
defines the direct access data set 
associated with unit number xx. 

Figure 61. Unit Assignment Table Entry for 
a Direct Access Data Set 



type macro instructions (see the publica- 
tion IBM System/360 Oper ating System; 
Supervisor and Da t a Managemen t Macro 
Instructions ) . 



OPERATION 



The processing of siibprogram IHCDIOSE is 
divided into five sections: file defini- 
tion, file initialization, read, write, and 
termination. When a section receives con- 
trol, it performs its functions and then 
returns control to the caller (either the 
FORTRAN load module or IHCFCOMH) . 



File Definition Section 



The pointers to the parameter lists are 
inserted into the unit assignment table 
entries by subprogram IHCDIOSE when it 
receives control from the initialization 
section of the FORTRAN load module being 
executed. 



The file definition section is entered 
from the FORTRAN load module, via a 
compiler-generated calling sequence, if a 
DEFINE FILE statement is included in the 
FORTRAN source module. The file definition 
section performs the following functions: 



Checks for the redefinition of each 
direct access unit number. 



BUFFERING 



All direct access input/output opera- 
tions are double buffered. (The double 
buffering scheme may be overridden by the 
user if he specifies in his DD statements: 
BUFN0=1.) This implies that during data 
control block opening, two buffers will be 
obtained for each data set. The addresses 
of these buffers are given alternately to 
subroutine IHCFCOMH as pointers to: 

• Buffers to be filled in the case of 
output. 

• Data that has been read in and is to be 
processed in the case of input. 



Each buffer has its own DECB. This 
increases input/output efficiency by over- 
lapping of input/output operations. 



COMMUNICATION WITH THE CONTROL PROGRAM 



In requesting services of the control 
program BSAM and BDAM routines, the IHC- 
DIOSE subprogram uses L and E forms of S- 



Enters the address of each direct 
access unit number's parameter list 
into the appropriate unit assignment 
table entry. 

Establishes addressability for subpro- 
gram IHCDIOSE within the IHCFCOMH 
subprogram. 



Each direct access unit nTimber appearing 
in a DEFINE FILE statement is checked to 
see if it has been defined previously. If 
it has been defined previously, the current 
definition is ignored. If it has not been 
defined previously, the address of its 
parameter list (i.e, , the definition of the 
unit number) is inserted into the proper 
entry in the unit assignment table. The 
next unit number, if any, is then obtained. 



When the last unit number has been proc- 
essed in the above manner, the file defini- 
tion section stores the address of IHCDIOSE 
into the FDIOCS field within IHCFCOMH. 
This enables subprogram IHCFCOMH to link to 
IHCDIOSE when IHCFCOMH encounters a direct 
access input/output statement. control is 
then returned to the FORTRAN load module to 
continue normal processing. 
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File Initialization Section 



The file initialization section receives 
control from the IHCFCOMH subprogram 
whenever input or output is requested for a 
direct access data set. The processing 
performed by the initialization section 
depends on whether or not an input/output 
operation was previously requested for the 
data set. 



NO PREVIOUS OPERATION ; If no operation was 
previously requested for the data set spec- 
ified in the current input/output request, 
the file initialization section first con- 
structs a unit block for the data set. 
(The GETMAIN macro instruction is used to 
obtain the main storage for the unit 
block. ) The address of the unit block is 
inserted into the appropriate entry in the 
unit assignment table. 

The file initialization section then 
reads the JFCB (job file control block) via 
the RDJFCB macro instruction. The value in 
the BUFNO field of the JFCB is inserted 
into the DCB skeleton in the unit block. 
This value indicates the number of buffers 
that are obtained for this data set when 
its data control block is opened. If the 
BUFNO field is null (i.e., if the user did 
not include the BUFNO subparameter in the 
PD statement for this data set), or other 
than 1 or 2, the file initialization sec- 
tion inserts a value of two into the DCB 
skeleton. 

The file initialization section next 
examines the JFCBIND2 field in the JFCB to 
determine if the data set specified in the 
current input/ output request exists. If 
the JFCBIND2 field indicates that the spec- 
ified data set does not exist, and if the 
current request is a write, a new data set 
is created, (If the current request is a 
read, an error is indicated and control is 
returned to subprogram IHCFCOMH which may 
terminate load module execution. If the 
current request is a find, the request is 
ignored, and control is returned to the 
IHCFCOMH subprogram. ) If the JFCBIND2 
field indicates that the specified data set 
already exists, a new data set is not 
created for BDAM use. 

If the specified data set is already 
opened when the file initialization section 
is entered, the following checks are made: 
(1) If the data set is already opened for 
BDAM, the appropriate branch is taken to 
perform a READ or WRITE operation. (2) If 
the specified data set has been opened for 
BSAM, then the data set is closed, since an 
input/output error must have occurred dur- 
ing the formatting of the data set. The 
data set is then reopened to provide a 



fresh start. The file initialization sec- 
tion processing for a data set to be 
created, and for a data set that already 
exists is discussed in the following 
paragraphs. 

Data Set To Be Created ; The data control 
block for the new data set is first opened 
for the BSAM, load mode, WRITE macro 
instruction. The BSAM WRITE macro instruc- 
tion is used to create a new data set 
according to the format specified in the 
parameter list for the data set in a DEFINE 
FILE statement. The data control block is 
then closed. Subsequent file initializa- 
tion section processing after creating the 
new data set is the same as that described 
for a data set that already exists (see 
"Data Set Already Exists"). 



Data Set Alre ady Exists ; The data control 
block for the data set is opened for direct 
access processing by the BDAM routines. 
After the data control block is opened, the 
file initialization section fills in 
various fields in the unit block: 

• The number of records in the data set 
is inserted into the RECNUM field. 

• The address of the DECB skeletons 
(DECBA and DECBB) are inserted into the 
CURBUF and the NXTBUF fields, 
respectively. 

• The addresses of the input/output buf- 
fers obtained during data control block 
opening are inserted into the appropri- 
ate DECB skeletons. 

• The address of the BLKREFA and the 
BLKREFB fields in the unit block are 
inserted into the appropriate DECB 
skeletons. 

Note ; If the user specifies BUFN0=1 in the 
DD statement for this data set, only one 
input/output buffer is obtained during data 
control block opening. In this case, the 
NXTBUF field, the BLKREFB field, and the 
DECBB skeleton are not used. 

Subsequent file initialization section 
processing for the case of no previous 
operation depends upon the nature of the 
input/output request (FIND, READ, or 
WRITE) . This processing is the same as 
that described for the case of a previous 
operation (see "Previous Operation"). 



PREVIOUS OP ER ATIO N; If an operation was 
previously requested for the data set spe- 
cified in the current input/output request, 
the file initialization section processing 
depends upon the nature of the current 
input/output request. 
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If the current request is either a find 
or a read, control is passed to the read 
section. 



If the current request is a write, con- 
trol is passed to the secondary entry in 
the write section. 



Read Section 



RECORD NOT I N BU FFER: If a record is not 
in the buffer, the read section first 
obtains the address of the buffer to be 
used for the current request. The relative 
record number of the record to be read is 
then inserted into the appropriate BLKREF 
field in the unit block (i.e., BLKREFA or 
BLKREFB) . The proper record is then read 
from the specified data set into the buff- 
er. Subsequent read section processing for 
the case of a record not in the buffer is 
the same as that described for a record in 
the buffer (see "Record in Buffer"). 



The read section of subprogram IHCDIOSE 
processes read and find requests. The read 
section may be entered either from the file 
initialization section of IHCDIOSE , or 
from IHCFCOMH subprogram. In either case, 
the processing performed is the same. In 
processing read and find requests, the read 
section performs the following functions: 

• Reads physical records into the 
buffer (s) obtained during data control 
block opening. 

• Makes the contents of these buffers 
available to the IHCFCOMH subprogram 
for processing. 

• Updates the associated variable that is 
defined in the DEFINE FILE statement 
for the data set. 



Note 1 ; Record retrieval can proceed con- 
currently with CPU processing only if the 
user alternates FIND statements with READ 
statements in his program. 

Note 2 : If an input/output error occurs 
during reading, the control program returns 
control to the synchronous exit routine 
(SYNADR) within subprogram IHCDIOSE . The 
SYN/^R routine sets a switch to indicate 
that an input/output error has occurred, 
and then returns control to the control 
program. The control program completes its 
processing and returns control to the IHC- 
DIOSE subprogram. The IHCDIOSE subprogram 
interrogates the switch, finds it to be 
set, and passes control to the input/output 
error routine of siabprogram IHCFCOMH (see 
"Error Processing"). 



The read section, upon receiving con- 
trol, first checks to see if the record to 
be found or read is already in an input/ 
output buffer. Subsequent read section 
processing depends upon whether the record 
is in the buffer. 



RECORD IN BUFFE R: If a record is in the 
buffer, the read section determines whether 
the current request is a find or a read. 

If the current request is a find, the 
associated variable for the data set is 
updated so that it points to the relative 
position within the direct access data set 
of the record that is in the buffer. Con- 
trol is then returned to the IHCFCOMH 
subprogram. 

If the current request is a read, the 
read operation that read the record into 
the buffer is checked for completion. The 
read section then places the address of the 
buffer and the size of the buffer into 
registers for use by subprogram IHCFCOMH. 
The associated variable for the data set is 
updated so that it points to the relative 
position within the direct access data set 
of the record following the record just 
read. Control is then returned to the IHC- 
FCOMH subprogram. 



Write Section 



The write section of subprogram IHCDIOSE 
processes write requests. The write sec- 
tion may be entered either from the file 
initialization section of IHCDIOSE , or 
from IHCFCOMH. The processing performed by 
the write section depends upon where it is 
entered from. 



PROCESSI NG IF ENTERED FROM FILE INITIA LIZA - 
TION SECTION ; If the write section is 
entered from the file initialization sec- 
tion of the IHCDIOSE subprogram, no writing 
is performed. The write section only pro- 
vides subprogram IHCFCOMH with buffer space 
in which to place the record to be written. 
The relative record ntimber of the record to 
be written is inserted into the appropriate 
BLKREF field (i.e., BLKREFA or BLKREFB). 
(The record is written the next time the 
write section is entered. ) For a formatted 
write, the buffer is filled with blanks. 
For an unformatted write, the buffer is 
filled with zeros. The write section then 
places the address of the buffer and the 
size of the buffer into registers for use 
by subprogram IHCFCOMH. Control is then 
returned to the IHCFCOMH subprogram. 



200 



PROCESSING IF ENTERED FROM IHCFCOMH ; Each 
time the write section is entered from IHC- 
FCOMH, it writes the contents of the buffer 
onto the specified data set. Subsequent 
write section processing for entrances from 
IHCFCOMH is the same as that described for 
entrances from the file initialization sec- 
tion of IHCDIOSE (see "Processing If 
Entered from File Initialization Section"). 
In addition, the associated variable is 
modified prior to returning to IHCFCOMH. 
The associated variable for the data set is 
updated so that it points to the relative 
position within the direct access data set 
of the record following the record just 
written. 

Note 1 ; The writing of physical records by 
this section is overlapped. That is, while 
subprogram IHCFCOMH is filling buffer A, 
buffer B is being written onto the output 
data set. When buffer A has been filled, 
the write from buffer B is checked for com- 
pletion. Upon completion of the write 
operation, the IHCFCOMH subprogram starts 
placing data into buffer B. In addition, a 
write from buffer A is initiated. 

Note 2 ; If an input/output error occurs 
during writing, the control program returns 
control to the synchronous exit routine 
(SYNADR) within the IHCDIOSE s\ibprogram. 
The SYNADR routine sets a switch to indic- 
ate that an input/output error has 
occurred, and then returns control to the 
control program. The control program com- 
pletes its processing and returns control 
to the IHCDIOSE subprogram. Subprogram 
IHCDIOSE interrogates the switch, finds it 
to be set, and passes control to the input/ 
output error routine of subprogram IHCFCOMH 
(see "Error Processing"). 



directly from the problem program — i.e., 
for error conditions 234 and 235. The 
second part of the common subroutine is 
used for those errors as well as for errors 
detected in that portion of subprogram IHC- 
DIOSE called from the IHCFCOMH subprogram 
— i.e., error conditions 231-233 and 236- 
237. It puts the data set reference number 
into the last four bytes of the error mes- 
sage and links to the error monitor. 

For error condition 232, the nximber of 
the record requested is placed in the 
parameter list before calling the common 
subroutine. For error conditions 218 and 
237, the DCB address is placed in the 
parameter list. 



Termination Section 



The termination section of the IHCDIOSE 
subprogram receives control from the load 
module termination routine of the IHCFCOMH 
subprogram. The function of this section 
is to terminate any pending input/output 
operations involving direct access data 
sets. The unit blocks associated with the 
direct access data sets are examined by 
IHCDIOSE to determine if any input/output 
is pending. The CHECK macro instructions 
are issued for all pending input/output 
operations to ensure their completion. 

The data control blocks for the direct 
access data sets are closed, and the main 
storage occupied by the unit blocks is 
freed via the FREEMAIN macro instruction. 
Control is then returned to the load module 
termination routine of IHCFCOMH to complete 
the termination process. 



E rror Pro cessing 



The way in which errors are processed is 
dependent upon whether or not the extended 
error message facility was specified at 
system generation time. 

WITHOUT EXTENDED ERROR MESSAGE FACILITY : 
An error number is put into a parameter 
list and register 13 is set up to point to 
a save area in IBCOM, The user's save area 
is linked to this save area. The error 
monitor is then called. 

WITH EXTENDEp ERROR MESSAGE FACILITY : A 
two-part common subroutine is called to 
prepare for a call to the error monitor. 
The first part of the subroutine links save 
areas as described when no error message 
facility has been specified. It is used 
only when an error occurs in the portion of 
subprogram IHCDIOSE which was called 



IHCIBERH 



Subprogram IHCIBERH, a member of the 
FORTRAN system library (SYSl.FORTLIB) , 
processes object-time source statement 
errors. The IHCIBERH subprogram is entered 
when an internal statement number (ISN) 
cannot be executed because of a source 
statement error. 

The ISN of the invalid source statement 
is obtained (from information in the call- 
ing sequence) and is then converted to 
decimal form. The IHCIBERH subprogram then 
links to subprogram IHCFCOMH to implement 
the writing of the following error message: 

IHC230I - SOURCE ERROR AT ISN 

XXXX - EXECUTION FAILED AT SUB- 
ROUTINE (xxxx) 
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After the error message is written on 
the user-designated error output data set, 
subprogram IHCIBERH passes control to the 
IBEXIT routine of subprogram IHCFCOMH to 
terminate execution. 

Chart 30 illustrates the overall logic 
of the IHCIBERR subprogram. 



Further information about traceback, 
including an example of output, is con- 
tained in the publication IBM Svstem/360 
Operating System; FORTRAN IV (G and H) 
Programmer's Guide , Form C28-6817. 



IHCFINTH 



IHCTRCH 



Subprogram IHCTRCH, a member of the 
FORTRAN system library (SYS1 .FORTLIB) , 
processes terminal errors detected by 
FORTRAN library subroutines at object time, 
The IHCTRCH subprogram is entered when an 
error is detected in order to print a 
traceback map. After this is accomplished, 
the job is terminated unless the extended 
error message facility has been requested. 

Subprogram IHCTRCH issues the following 
message: 



IHCxxxI 

TRACEBACK FOLLOWS ROUTINE 

REG„ 15 REG. REG. 1 



ISN 



REG. m 



where: 

XXX is the error code (in decimal 
form) that it obtains from the calling 
sequence. 

If the error occurred in subprogram IHC- 
FCOMH, IHCFCVTH, IHCNAMEL, IHCDIOSE , or 
IHCFIOSH, the IHCTRCH subprogram sets up an 
areci that can be processed as a standard 
save area for the first traceback line. 

For each traceback line, subprogram 
IHCTRCH gets the name of the called rou- 
tine, the internal statement ntamber, if 
any, of the call within the calling rou- 
tine, and the contents of register 14, 15, 
0, and 1 in hexadecimal. 

After printing each line, subprogram 
IHCTRCH checks to ascertain whether or not 
the called routine was the main FORTRAN 
routine. If it was tlie entry point is 
printed, in hexadecimal and a branch is 
made to IBEXIT. If it was not, a traceback 
loop-check routine is entered, which builds 
and checks a table of save area addresses. 
If the table is full or if a loop is 
detected, IHCTRCH prints TRACEBACK TER- 
MINATED and then prints the main FORTRAN 
routine entry point and branches to IBEXIT. 

Subprogram IHCTRCH uses the IHCFCVTH 
subprogram to convert to printable hexade- 
cimal format and it subroutine IHCFIOSH for 
printing. 



The module IHCFINTH processes asyn- 
chronous program interrupts. Every FORTRAN 
main program notifies the system' s first 
level interrupt handler (via a SPIE macro 
instruction) to transfer to the entry point 
ARITH# in module IHCFINTH in the event of a 
program interrupt. 

FORTRAN requests interrupt service for 
the program interrupts listed below. All 
others cause job termination by the system. 
(For a description of program interrupts, 
see the publication IBM System/360: Prin- 
ciples of Operation , Form A22~6821. ) 



Code 



9 


11 


12 


13 


15 



Description 
Fixed-point divide 
Decimal divide 
Exponent overflow 
Exponent underflow 
Floating-point divide 



Codes 8 and 14 are masked so that no 
interrupt occurs. 

If boundary alignment adjustments were 
requested when the system was created, then 
interrupt 6 specification is also re- 
quested. The processing for specification 
interrupts is handled by the module 
IHCADJST, however. 

The services performed by the interrupt 
processing routine IHCFINTH are as follows : 

1. A message is printed that identifies 
the interrupt. 

2. Switches are set for exponent over- 
flow, exponent underflow, and divide 
check for the FORTRAN subprograms CALL 
OVERFL(J) and CALL DVCHK(J). 

3. Result registers are altered for 
exponent overflow and underflow as 
follows: 

Overflow — maximum floating-point 
number 

Underflow — zero 

In addition, if the operation was an 
add or subtract and exponent underflow 
occurred, then the condition code is 
set to 0. 
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When the extended error message facility 
has been requested, then the module IHC- 
FINTH has the ability to accept a user exit 
and control the printing of messages and 
the number of occurrences of the various 
interrupts. The user exit may provide an 
alternate value to be placed in the result 
register for underflow and overflow before 
execution continues. 



The FORTRAN library provides the error 
message facility through the following 
services: 



1. Each module that detects an error 

calls the error monitor. The module 
can accept a return from the error 
monitor and supply a standard correct- 
ive action. 



IHCERRM 



The IHCERRM subprogram is the execution 
error monitor. Each FORTRAN library pro- 
gram that detects an error calls the 
IHCERRM module for error message service. 
The service available is dependent upon 
which of two options — basic message fa- 
cility or extended error message facility 
— was selected at system generation. 

When the basic facility is requested, 
each error causes job termination and a 
traceback map is produced. The messages 
printed on the object error unit will con- 
tain a description of the error situation 
if the error was detected by the mathemat- 
ical library. For other error situations, 
only an error code is printed. For a full 
description of these error codes, see the 
publication IBM System/360 Operating Sys- 
tem; FORTRAN (G and H) Programmer's Guide , 
Form C28-6817. 

When the extended error message facility 
is present, the error monitor is directed 
by the option table to perform one or more 
of the following actions: 

• Print a message 

• Terminate the job 

• Call a user-written routine for 
corrective action. Upon return from 
the user-written routine, the return is 
made to the caller of the error 
monitor. 

• Return to the caller of the error mon- 
itor an indication that standard 
corrective action is required. The 
routine that called the error monitor 
has the programming to provide the 
standard corrective action. 



To enable dynamic control of error 
occurrences and printing suppression, rou- 
tines can be called from the FORTRAN source 
language. 

Because error message printing can be 
suppressed, a summary of error occurrences 
is given before return to the system. 



2. An error monitor is supplied. 

3. Routines to change the option table 
are supplied. 

4. An option table is supplied. 

5. The exit code of the FORTRAN library 
provides for the printing of an error 
summary. 



The following is a description of the 
error monitor: 



The error monitor on initial entry will 
set a switch. If entered again before the 
switch is set to off, a recursive situation 
is detected and the job is terminated. 



The error monitor then retrieves the 
error entry from the option table and makes 
the following actions and tests in the 
order listed: 

1, Updates the current count of errors 
encountered. 

2, Does the current count of errors 
exceed the number of allowable errors, 
indicating that the job should be 
terminated? 

3, Does the current count of messages 
printed exceed the number of messages 
to be printed, indicating that message 
printing is to be suppressed? 

U, Should a traceback map be printed? 

5, Is a user exit specified? If it is, 
the exit routine, which must return to 
the error monitor, is called. 

6. Return to caller of the error monitor 
after turning off the switch that 
indicates that the error monitor has 
been entered. 



Charts 31 and 32 show the overall logic 
of the error monitor. 
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Alter Option Table Routine (IHCFOPT) 



The IHCFOPT routine allows the user to 
alter the option table, thereby achieving 
dynamic control over error occurrence has 
three entry points: ERRSTR, ERRSAV, and 
ERRSET, 



The option table consists of an entry 
for each error number and a preface of 8 
bytes. An option table entry for an error 
number is described in Table 36, 

If the extended error message facility 
has not been specified at system generation 
time, the option table is reduced to the 
preface alone. The option table preface is 
described in Table 37. 

To obtain an entry from the option 
table, the source program calls subroutine 
IHCFOPT through its entry name ERRSAV. 
When the requested entry is located in the 
option table, it is placed in the address 
passed in the call to ERRSAV. If the 
requested entry is not in the option table, 
a message is printed. 



To store an entry in the option table, 
the source program calls subroutine IHCFOPT 
through its entry name ERRSTR. If the 
requested entry exists in the option table, 
it is checked to see whether or not that 
entry can be modified. If it can be modi- 
fied, the entry passed to ERRSAV is placed 
in the option table to replace the previous 
entry. If the existing entry is unmodifi- 
able, a message so stating is printed. 

To change individual fields in the 
option table, the source program calls IHC- 
FOPT through its entry name ERRSET. If the 
requested entry exists in the option table, 
each field of the entry for which an 
alteration is requested is checked to see 
whether or not it contains a value of zero. 
(The IRANGE field for error IHC212I is an 
exception. ) If it does, that field will 
not be altered. If it does not, the field 
is replaced with the new field passed in 
the call to ERRSET. As parameters are 
processed, a check is made for an early end 
to the parameter list. 

Charts 33, 34, and 35 show the overall 
logic of the routine to alter the option 
table. 
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Table 36. Description of Option Table Entry 

r T -T T 



T 

I Default I 
Length j Settings^] Description 



Field 



H 



1 byte \ 102 



1 byte 



1 byte 

1 byte 

bit 

1 

2 
3 

4 
5 

6 

7 

4 bytes 



5** 





1 


(See 
Note 6) 



1 





Contains a count. When the count in this field matches field 
3, the job is terminated. The maximiom count is 255. A count 
of zero means unlimited number of occurrences. ^ Any count 
greater than 255 supplied ERRSET will set this field to zero. 

A count of the number of messages to be printed; message print- 
ing is suppressed after the count is exceeded. A count of 
zero means no messages are to be printed. 

Count of niomber of errors that have occurred, where means no 
errors have occurred. 

8 option bits defined as follows: 

Control character indicator 

= none, 1 = single space 
Table entry modifiable 

= no, 1 = yes (See Note 5) 
Extension of count of errors that have occurred 
Buffer contents to be printed 

= no, 1 = yes 
Unused (reserved) 
Unlimited number of messages allowed 

= no, 1 = yes 
Traceback required 

= no, 1 = yes 
Unused (reserved) 

Address of user' s exit routine. If the value of the entry is 
odd, standard corrective action is indicated. 



*-The default values shown apply to all error numbers unless excepted by a footnote. 
^Errors 208, 210, and 215 are set as unlimited, and errors 217 and 230 are set to 1. 
^When the user sets the count of allowed errors as unlimited, the FORTRAN job may loop 

endlessly unless the operator intervenes. 
**Error 210 is set to 10, and errors 217 and 230 are set to 1. 
^The entry for error 230 is not modifiable. 
«This entry is set to except for error numbers 212, 215, 218, 221, 222, 223, 224, and 

225. 



Table 37. Description of Option Table 



r T '-T " T 

I Field I Length | Default | Description 



U bytes 
1 byte 

1 byte 

1 byte 
1 byte 



95 
l=Bit 1 



Contains the count of the ntamber of entries in the Option Table 

Boundary alignment switch 
1=ALIGN, 0=NOALIGN 
Bit 1 of this byte contains the switch 

Error message handling selected 
FF=no, 00=yes 

For no error message facility, the default will be FF. 

For no error message facility, boundary align count is kept 
here. Default is then 10. 

Not used (reserved). 
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Chart 23. IHCFCOMH Overall Logic and Utility Routines 



SEF TABLE 38 FOR A BRIEF 
DISCUSSION OF EACH ROUTINE 
OF IHCFCOMH. 



****Pi3 ******** 1 
* LOAD * 
► MODULE 

**************:^ 



):****^2*** ******* 



♦ THE LOAD MODULE ENTERS 
IHCFCOMH VIA A COMPILER- 
GENERATED CALLING SEQUENCE. 



*+*+*♦♦♦*♦♦* 



REQUEST TYPE 


CHART 


MAJOR PROCESSING 
ROUTINES 


SUBROUTINES CALLED 


SEQUENTIAL AND 
DIRECT ACCESS 
READ /WRITE 
REQUIRING A FORMAT 


2ltA2 


FRDWF, FWRWF, FIOLF, 
FIOAF,FENDF 


IHCFIOSH (FOR SEQUENTIAL ACCESS,) 

IHCDIOSE (FOR DIRECT ACCESS) , AND 

CONVERSION ROUTINES — FCVII, 

FCVIO, FCVEI , FCVEO, FCVDI , FCVDO , FCVLI , 

FCVLO,FCVZI,FCVZO,FCVFI,FCVF0,FCVAI, 

FCVAO,FCVGI,FCVGO 


SEQUENTIAL ACCESS 
AND DIRECT ACCESS 
READ/WRITE NOT 
REQUIRING A FORMAT 


2«F2 


FRDNF, FWRNF, FIOLN, 
FIOAN.FENDN 


IHCFIOSri (FOR SEQUENTIAL ACCESS) 
IHCDIOSE (FOR DIRECT ACCESS) 


READ USING 
NAMELIST 


25E1 


FRNDL 


IHCFIOSH, AND CONVERSION ROUTINES 
FCVEI , VCVDI , FCVAI , FCVLI , 
FCVGI.FCVCI, FCVII, FCVFI 


WRITE USING 
NAMELIST 


25L5 


FWDNL 


IHCFIOSH, AND CONVERSION ROUTINES 
FCVEO, FCVDO, FCVAO,FCVIC, 
FCVGO , FCVCO , FCVIO , FC VFO 


DEVICE 
MANIPULATION 


25E3 


FBKSP.FRWND.FEOFM 


IHCFIOSH 


WRITE TO 
OPERATOR 


25G3 


FSTOP, FPAUS 


NONE 


DIRECT ACCESS 
FIND 


2KF2 


FRDNF, FENDN 


IHCDIOSE 



-- UTILITY ROUTINES -- 



****G1* ******** 

* FROM * 
+FSTOP OR IBFERR* 

♦ * 
*************** 



****Q2********* 

* FROM MODULE * 
♦DETECTING ERROR* 

* A 

*************** 



EXCEPT 

***+G3********* 

* * 

* FROM IHCFIOSH * 

* * 
*************** 



«»**G1| ********* 
► FROM < 
* LOAD MODULE * 
y 4 

*************** 



**+*G5*+**+**** 
* FROM 

!■ IHCFIOSH OF 
► IHCDIOSE 

**************i 



V 
t****j^1* ********* 

^ IBEXIT * 

t-*-*-*-* -*-*-*-* 

* CLOSE DATA * 
►SETS (TERMINATE* 
► EXECUTION) * 
***************** 



*-*-*-♦- 



***************** 



DETERMINE IF ♦ 

END PARAMETER * 

SPECIFIED * 

**************** 



* PROCESS 

* ARITHMETIC 

* INTERRUPTION 
*************** 



*_*_♦_*_*_♦_♦-*- 

* DETERMINE IF 

* ERR PARAMETER 

* SPECIFIED 
**************** 



♦***J1********* 
* TO < 

► OPERATING ■* 
^ SYSTEM i 

*************** 



****J2********* 

* * 

* TO IBEXIT + 

* * 
*************** 

IF EXECUTION 
IS TO CONTINUE 
RETURN TO CALLER 



****J3**+****** 

* TO LOAD * 

* MODULE IF * 

* SPECIFIED * 
*************** 

IF PARAMETER NOT 
SPECIFIED, EXIT IS 
TO ERRMON 



****JH********* 

* * 
*T0 LOAD MODULE * 

* * 
*************** 



****J5 ********* 

* TO LOAD * 

* MODULE IF * 

* SPECIFIED * 
*************** 

IF PARAMETER NOT 
SPECIFIED, EXIT IS 
TO ERRMON 



206 



Chart 24. Implementation of READ/WRITE/FIND Source Statements 



FRDWF/FWRWF 
*****[i,2 ********** 
+ PERFORM OPENING* 
+ OPERfi.TIOMS FOR * 
>* REZiD/ WRITE * 

* REQUIRItNIG + 

* A FORf-lAT * 
♦*********+****+* 



FIOAF/FIOLF 
*+***B2***+****** 

* PERFORM I/O * 

* LIST SECTION * 

* OPERATIONS *< 
+ ON LIST ITEM * 

* + 



* CLOSE OUT 

* I/O 

* OPERATION 



*****BH* ********* 
*GET LIST ITEM. + 

* CALL I/O LIST * 
-* SECTION OF +< 

* IHCFCOMH + 



**4 



ti************* 



LAST 
LIST 
ITEM 



*+*++DH+*+*****++ 

* ♦ 

* CALL CLOSING * 
-* SECTION OF * 

* IHCFCOMH * 

* * 



THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
I/O LIST ITEM 
IS ENCOUNTERED. 



***++Et**+****+** 

♦ * 

♦ CONTINUE WITH * 
+ LOAD MODULE * 
+ EXECUTION * 

♦ * 



THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
ALL I/O LIST ITEMS 
ARE PROCESSED. 



FRDNF/FWRNF 
++**+F2********** 
♦PERFORM OPENING* 
♦OPERATIONS FOR * 
->*READ/ WRITE/FIND* 

* NOT REQUIRING + 

* A FORMAT * 
+*++***+*+**♦♦++* 



FIOLN/FIOAN 
♦t+**G2********* 

* PERFORM I/O 

* LIST SECTION 

* OPERATIONS 

* ON LIST ITEM 
* 
*♦*++*********** 



* CLOSE OUT 

* I/O 

* OPERATIONS 
* 
♦**+*****♦**** 



*****QH********** 

*GET LIST ITEM. * 

* CALL I/O LIST * 
-♦ SECTION OF *< 

* IHCFCOMH * 
+ * 
♦*♦*+*++♦**+***** 



LAST 
LIST 
ITEM 



*****JH*********^ 

* ^ 

* CALL CLOSING * 
-* SECTION OF * 

* IHCFCOMH * 



THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
I/O LIST ITEM 
IS ENCOUNTERED. 



THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
ALL I/O LIST ITEMS 
ARE PROCESSED. 



****K^* ********* 

* 

CONTINUE WITH * 

LOAD MODULE * 

EXECUTION * 

* 

***♦+**♦*♦*++**♦ 
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chart 25. Device Manipulation, Write-to-Operator, and READ/WRITE Using NAMELIST Routines 



DEVICE MAtJIPULATION 



i 

IhPLExMENT * 

'.EAD USING * 

fJAMELIST * 



BACKSPACE 



FBKSP 

+ IMPLEMEUT + 

+ BACKSPACE * 

* SOURCE + 

* STATEi^EMT * 



♦+*****< 



t***4 



k« * 



V 

* DETERMINE * 

* TYPE OF * 
+ DEVICE * 

* MANIPULATION ♦ 



********* 


******** 




REWIND 
FRW.'JD \ 


' 


END FILE 
FEOFM 



t*03*********t 

* IMPLEMENT 

* REWIND 

* SOURCE 

* STATEMENT 
+ 
************** 



****E2********* 
^ TO * 

► LOAD * 
* MODULE ' 

*************** 



*****iyH ********* 

* IMPLEMENT 

* END FILE 

* SOURCE 

+ STATEMENT 

* 

**************** 



WRITE USING 

NAMELIST 

***** 

♦25 ♦ 

♦ E5* 

+ * 



^*******i 



* IMPLEMENT 

* WRITE USING 

* NAMELIST 
* 
+****♦+*+****** 



* **+Fl** + ** ♦*^ 
t TO 

• LOAD 

• MODULE 
**++++*+****+* 



V 
****F5+******** 
f TO * 

► LOAD * 

► MODULE ♦ 
*************** 



V 

*****QJ********** 

* DETERMINE * 

* TYPE OF * 
-+ WRITE TO *- 

* OPERATOR * 

* ♦ 
***************** 



FSTOP 

*** + *H2** + + *****'' 

* IMPLEMENT n 
+ STOP 1 

* SOURCE * 

* STATEMENT * 



***++^ 



k******* 



FPAUS 

* + ***Hl(****»***** 
+ IMPLEMENT ♦ 

* PAUSE * 

* SOURCE * 

* STATEMENT * 

* * 
***************** 



V 

****j2*****+**« 
► TO 
* IBEXIT 

l< 

*************** 



****JI(********* 
f TO * 

<• LOAD * 
* MODULE ■• 

*************** 
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Table 38. IHCFCOMH Subroutine Directory 

Function 



r T- 

I Subroutine | 



h 



EXCEPT j Checks for presence of END= parameter, and passes control to the load module 

I if present. 

FENDF I Closing section for a READ or WRITE requiring a format. 

FENDN I Closing section for a READ or WRITE not requiring a format. 

FEOFM I Implements the END FILE source statement. 

FERROR i checks for the presence of the ERR= parameter, and passes control to the 

I load module if present. 

FIOAF I I/O list section for list array of a READ or WRITE requiring a format. 

FIOAN I I/O list section for list array of a READ or WRITE not requiring a format. 

FIOLF I I/O list section for a list variable of a READ or WRITE requiring a format. 

FIOLN I I/O list section for a list variable of a READ or WRITE not requiring a 

I format. 

FPAUS I Implements the PAUSE source statement. 

FRDNF I Opening section of a READ not requiring a format. 

FRDWF I Opening section of a READ requiring a format. 

FRWND I Implements the REWIND source statement. 

FSTOP I Implements the STOP source statement. 

FWRNF I Opening section for WRITE not requiring a format. 

FWRWF (opening section for WRITE requiring a format. 

IBEXIT I Closes all data sets and terminates execution. 

IBFERR I Calls IHCTRCH to process terminal object-time errors. 

IBFINT I Processes program interruptions. 

FBKSP I Implements the BACKSPACE source statement. 



-^ 



Table 39. IHCFCVTH Subroutine Directory 

Function 



r T- 

I Subroutine | 



^ +_ 

FCVAI I Reads alphameric data. 

FCVAO I Writes alphameric data, 

FCVCI (Reads complex data. 

FCVCO I Writes complex data. 

FCVDI f Reads double precision data with an external exponent. 

FCVDO j Writes double precision data with an external exponent. 

FCVEI I Reads real data with an external exponent. 

FCVEO 1 Writes real data with an external exponent. 

FCVFI I Reads real data without an external exponent. 

FCVFO I Writes real data without an external exponent. 

FCVGI I Reads general type data. 

FCVGO I Writes general type data. 

FCVII I Reads integer data. 

FCVIO i Writes integer data. 

FCVLI I Reads logical data. 

FCVLO j Writes logical data. 

FCVZI I Reads hexadecimal data. 

FCVZO [Writes hexadecimal data. 

L J.. . J 
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Chart 26. IHCFIOSH Overall Logic 



Frocs 

+*+*A3****+* 

♦ Fdoa 

* IHCFCOMH 
♦+♦♦*♦♦**+*+ 



SEE TABLE 4 FOR A BRIEF 
DESCRIPTION OF THE FUNCTION 
OF EACH IHCFIOSH ROUTINE. 



♦♦B3*+**+****+ 

+ 

DETriSMINE ♦ 

OPERATION ♦ 

TYPE + 

************** 



INITIALIZATION 



► ♦CI* 



^*******A 



DECODE DSRN ♦ 

AND BUILD UNIT +<- 

BLOCK (IF + 

NECESSARY) * 
**************** 



V 

* ****Y)'l*** ******* 
♦OPEN DATA CON- * 
tTROL BLOCK FOR * 
♦DATA SET IF NOT* 

* PREVIOUSLY * 

* OPENED * 
***************** 



DCB 
OPENED 
, PROPERLY 



D .</. 


FRITE .*. 


C2 *. 


C3 * 


. * ANY * . 




. * MORE RCDS *. YES 


. * OUTPUT 


.THIS BLOCK TO.* T 


*. BUFFER 


+. BS PRO- .* 


*. FULL 


*.CESS .* 


* . 



tc****^^** ******** 

J: * 

K DETERMINE * 
^ RECORD FORMAT * 
► AND BLOCKING * 
It * 

if**************** 



* CURRENT 

OP. DEVICE 
♦. MANIP. 



*****v)2** ******** 

* READ * 
♦NEXT BLOCK INTO* 

* THIS BUFFER. * 

* SWITCH BUFFER * 
+ POINTERS ♦ 



* + + + *£;2********** 

* * 
+ CHECK RESULT * 

* OF READ INTO *- 
+ OTHER BUFFER * 
+ * 
***************** 



***** 
*27 * 
* B2* 



+**+*p2+***+** 



>* MESSAGE * -I 

* IHC2I9C + 

* * J 
***************** y 



**+**D3********* 
♦WRITE CONTENTS 

* OF THIS BUF- 

* FER. SWITCH 
+ BUFFER 

* POINTERS 
**************** 



*****£ J********** 

* * 

* CHECK RESULT ♦ 
+ OF WRITE FROM ♦ 

♦ OTHER BUFFER ♦ 

♦ ♦ 
*♦♦*++♦**+++♦+♦♦♦ 



♦ ♦♦ + 
+ 27 ♦ 

>♦ B2 



► CHECK 

^ STATUS OF 

► UNIT 

►**♦♦♦♦♦♦+♦♦♦♦ 
*♦♦♦ 



DETER- 
MINE OP- 
. ERATION 
♦ . TYPE . ♦ 



BKSP 

*****EH********** 

♦ ISSUE ♦ 

♦ BACKSPACE. ♦ 

♦ INDICATE * 

♦ DATA . SET ♦ 

♦ TYPE + 
*+*+*+*+++♦♦♦♦+♦♦ 



* + + + 



i:****pl^********** 
K ♦ 

► ISSUE CLOSE + 
!■ (TYPE=T) ♦ 
* WITH LEAVE * 

► OPTION ♦ 
►*♦+♦♦♦*♦♦♦♦♦*♦*♦ 



*****(^ti********** 

* * 

* FREE I/O + 
+ BUFFERS ♦ 

* FOR THIS ♦ 
+ DATA SET * 



♦ ♦ + * 

♦ 27 + 
->* D2 * 



*****(2'^* ********* 

* * 

* CHECK ANY ♦ 

♦ OUTSTANDING +< 
+ INPUT OR + 

♦ OUTPUT ♦ 
***************** 





+ LAST ♦ 






DSRN 

'♦'yes 

1 +*♦* 


+ 




♦ 27 + 




l->* B2 


♦ 








♦ ♦♦ ♦ 




WND 






+*+*+E5+++****+++ 


* 




+ 


* 


issue 


* 


->* 


CLOSE 


* 


* 


WITH REREAD 


* 


+ 


OPTION 


* 


** 


****** *♦*++++++ 




♦ + *♦ 






♦ 27 * 




l->* B2 


* 



READ 

OR 
WRITE 



►♦Jl********^ 

READ 

A 
BLOCK H 

^*********** 



**** 
FIORET V 

*****j^l*** ******* 

♦ PASS CURRENT ♦ 
♦RECORD POINTER ♦ 

♦ AND LOGICAL + -, 

♦ RECORD LENGTH + | 
TO IHCFCOMH 



♦ ♦' 



i:******4 



*♦ + ♦ 



210 



chart 27. Execution- Time Input/Output Recovery Procedure 



THE I/O SUPERVISOR IS ENTERED 
VIA DATA MANAGEMENT ROUTINE 
WHEN IHFIOSH OR IHCDIOSE 
ISSUES A MACRO INSTRUCTION 



***** 
*27 * 
* B2* 



HAS AN 
EOF BEEN 
. READ 



+****B3********** 

* * 

* ISSUE + 
>* MESSAGE *- 

* IHC217I * 

* + 
***************** 



F2 i 
**** 



*****C1* ********* 

* * 

* ♦ NO . 

* RETURN TO *< — ^< *. 

* IHCFCOMH * 

***************** I 

**** 



* CI * 

* * 
*♦ + * 



V 

*+**Dl********* 

FORTRAN ■• 

► LOAD * 

^ MODULE ^ 

*************** 

CONTINUES 

NORMAL 

PROCESSING 



I/O 

ERROR IN 

lOS 



♦**+*E2********** 

* * 

* ISSUE + 

* MESSAGE *< 

* IHC218I * 

* ♦ 
***************** 



**** 

♦ 27 * 

* F2 *-> 



* **♦ 

**i,**-p2** ******** 

* * 

* PASS ♦ 

* ABORT CODE * 

* TO SCHEDULER * 

* ♦ 
***************** 



****Q2********* 



ISSUES ABEND 
MESSAGE AND 
THEN CONTINUES 
NORMAL PROC- 
ESSING 



->* 



****+C3**+******* 
*DATA MANAGEMENT* 

♦ RETRY * 
APPROPRIATE *- 

♦ NUMBER * 

♦ OF TIMES * 
***************** 



*****D-i**** ****** 

* IHCFCOMH * 

* DETERMINES * 

* IF AN INVALID +<- 

* BUFFER HAS * 

* BEEN READ * 
***************** 



. * HAS * 

. BUFFER BEEN 
*.READ YET .* 



. ♦ WIND OR *. NO 

. BACKSPACE .* 

*.BEEN IS- .* 
*.SUED .* 



+****G3 ****+♦***♦ 

* + 

* VOID * 

* ABORT CODE + 

* IN IHCFCOMH * 

* * 
**********^,****** 



****H3*****+*** 

* FORTRAN * 

* LOAD * 

* MODULE * 
*************** 

CONTINUES 

NORMAL 

PROCESSING 



* I/O 

ERROR BEEN 
* . CORRECTED . 



*****DH********** 

* * 

* RETURN * 
-* ABORT CODE * 

* TO IHCFCOMH ♦ 
+ * 
***************** 
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• chart 28. IHCDIOSE Overall Logic — File Definition Section 



NOTE : 

THK FILE DEFINITION 

SECTION IS ENTERED 

FROM ThE FORTRAN 

LOAD MODULE VIA fi 

COMPILER-GENERATED 

CALLING SEQUENCE. 



****A3********* 

* FORTRAN LOAD '• 

* MODULE ^ 

* A 

^:iH:*t*t ******** 



SEE TABLE 41 FOR A 
BRIEF DESCRIPTION OF THE 
FUNCTION OF EACH IHCDIOSE 
ROUTINE. 



*****^jt ********* 

* GET FIRST * 

* UNIT NUMBER ♦ 

* (DSRN) FROM ♦ 
♦PARAMETER LIST * 



*******i 



It******** 



V 
****+C3 ********** 

♦ INSERT UNIT * 

* NUMBER'S * 
*PARAMETER LIST * 
♦ADDRESS IN UNIT* 
*ASSIGNMENT TBL * 
***************** 



.* LAST UNIT 

. NUMBER IN 

*. PARAMETER. 

♦.LIST .* 



*****Q^ ********** 

* GET NEXT * 

* UNIT NUMBER * 
>* (DSRN) FROM * 

* PARAMETER LIST + 

* * 
***************** 



DELAST V 

*****-£2*** ******* 

* ESTABLISH * 
♦LINKAGE BETWEEN* 

* IHCDIOSE AND * 

* IHCFCOMH * 



*****n 



!■♦♦♦***♦* 



****P2********* 

► FORTRAN * 
» LOAD ♦ 

► MODULE * 
*************** 



212 



chart 29, 



IHCDIOSE Overall Logic 
Sections 



- File Initialization, READ, WRITE, and Termination 



IBCENTRY 

****R2*******< 
* IHCFCOMH 

**♦ + * + ♦ + * + + + *:4 



DETERMINE *. 
OPERATION . ' 
. TYPE . ♦ 



WRITE SECTION 
(PRIMARY ENTRY 
FROM IHCFCOMH) 



.1. 



.i. 



*C0;>I3TRUCT UNIT * 

* BLOCK. INSERT * 

* ADDR OF UNIT * 
+BLOCR INTO UNIT* 
♦ASSIGNMENT TBL * 
♦+♦+**♦*+♦*+****+ 



V 
**+**Dl**+****** 

* READ JOB FILE 

* CONTROL BLOCK 
+(JFCB). INSERT 

* BUFNO VALUE 

* INTO DCB 



* + 

* EXAMINE * 
*JFCBIND2 FIELD * 

* IN JFCB * 

* + 



NEW DATA 
SET TO BE 
. CREATED . 



k B2 * 
*♦** 
RDINBUF 

YES . * ' 



IS THIS 
A FIND 
REQUEST 



CHECK 

FOR I/O 

COMPLETION 

(•*********♦ + < 



V 

* + ** + 1^2********** 

* PLACE * 
+BUFFER POINTER * 
*AND BUFFER SIZE* 

* IN REGISTERS * 

* * 



V 
+ + ***j'2***** + *** 
*GET ASSOCIATED 

* VARIABLE'S 

* ADDRESS AND. 

* CURRENT 

* RECORD NUMBER 

*t** + ***:4t* * + + + ♦* 



K2 * 



* + * + + G2*******'t 



♦ .WRITE REQUEST.* >* 



OPEN * 

DCB FOR NEW * 

DATA SET * 

****+++*****+*♦ 



READ 
OR FIND 
REQUEST 



***+*Jl********** 



V 
*****H2****+***** 

* CREATE * 
♦AND FORMAT NEW * 
♦DATA SET USING + 

* BSAM WRITE ♦ 

* MAC^O ♦ 



►*+*+j2++**^^^*** 



♦♦♦♦♦B3^*+^****+* 

* + 

* OBTAIN ♦ 
>* ADDRESS OF ♦ 

* ItiPUT BUFFER ♦ 



V 
*****C3*******^+* 
♦INSERT RELATIVE* 

♦ RCD NO. OF RCD * 
*T0 BE READ INTO* 

♦ BLKREFA OR ♦ 

♦ BLKREFB FIELD ♦ 



♦♦♦♦♦*D3^*****++^* 



«4<=4(1(4:*^**H«*H'9t: 



WRITE * 

A 

y RECORD * 



** + **C !(*+**+*♦*** 

♦ OBTAIN NEXT * 
♦OUTPUT BUFFER, ♦ 

♦ BLANK OR ZEi^O * 

♦ DEPENDING ON * 
♦DATA SET FORMAT* 
****♦+♦+********♦ 



♦INSERT RELATIVE* 
*RCD NO. OF RCD * 

* TO BE WRITTEN * 
♦INTO BLKREFA OR* 

* BLKREFB FIELD * 
♦*******++**++*♦* 



, ♦ ANY * 
, PENDING I/O 
♦OPERATIONS. ♦ 



♦ WAIT 

♦ FOR I/O 

♦ COMPLETION 

4> «** I' ♦♦♦♦♦♦♦♦ ♦ 



!■******♦* 



* PLACE BUFFER 
-+ POINTER AND 

♦BUFFER SIZE IN 

* REGISTERS 



IS THIS 
A FIND 
REQUEST 



♦ IHCFCOMH 



♦CLOSE DCBS FOR * 

♦ DIRECT ACCESS ♦ 

♦ DATA SETS ♦ 

**i|<>4c4:*4'*4(*^*^***^ 



V 

♦♦♦*+E5^********* 

♦ FREE MAIN ♦ 

♦ STORAGE ♦ 

♦ OCCUPIED BY * 

♦ UNIT BLOCKS ♦ 

♦ ♦ 
♦♦+♦♦*++****+♦♦♦♦ 



UPDASSV 

* + * + *Fl(* + + + »*** 

* UPDATE 
♦ASSOCIATED VAR 

>* SO THAT IT 

* POINTS TO RCD 

* JUST READ 



*** 



* INDICATE * 


* CLOSE * 


♦ ERROR ♦ 


♦ DCB FOR DATA ♦ 


* * 


♦ SET * 


+ + 


* ♦ 


*******4:****4<**** 


♦**+♦*+*+**♦*♦**♦ 






*♦* + 
















♦ K2 ♦-> 








* * 








***♦ 




NSRETURN 




OPEN V 


V 


♦♦♦**K2****+**^^* 


♦♦♦♦Kt^^*^^+^*+ 


♦ * 


* * 


♦ OPEN DCB FOR ♦ 


♦ IHCFCOMH ♦ 


* DATA SET FOR ♦ 


* + 


♦ DIRECT ACCESS * 


+***+**+*+***++ 


♦ PROCESSING * 






+**+*♦** 


k4:«>(<*4'**4: 



♦ INSERT RECORD + 

♦ NUMBER INTO ♦ 
->* RECNUM FIELD ♦ 

* OF UNIT * 

* BLOCK * 
*♦*+♦****++***♦*+ 



V 
♦♦♦♦♦H3***^^^**** 
♦INSERT ADDR OF ♦ 
♦DECBA SKELETION+ 

♦ INTO CURBUF * 

♦ FIELD OF ♦ 

♦ UNIT BLOCK ♦ 



V 

♦***+j3********** 
♦INSERT ADDR OF * 
♦DECBB SKELETON * 

* INTO NXTBUF * 

* FIELD OF UNIT * 

* BLK IF 2 BFRS * 



** 



V 
*K3*^^^*^*+** 

INSERT ADDR OF ♦ 
I/O BFRS * 
INTO DECB *- 

SKELETON (S) IN * 
UNIT BLOCK * 

^^^^^■♦♦♦♦♦♦♦* + ^^ 



♦ UPDATE ♦ 
♦ASSOCIATED VAR ♦ 

♦ SO THAT IT ♦- 
♦POINTS TO NEXT ♦ 
♦RCD IN DATA SET* 
**++♦♦♦++**+♦*♦*♦ 



*****IIH* ********* 
♦INSERT ADDR OF * 

* BLKREFA INTO ♦ 
->^DECBA SKELETION+ 

* IN UNIT ♦ 

* BLOCK * 
***************** 



V 
*****JH* ********* 
♦INSERT ADDR OF ♦ 

♦ BLKREFB INTO ♦ 
♦DECBB SKELETON ♦ 

♦ IN UNIT BLOCK * 

♦ IF TWO BFRS ♦ 
***************** 



**** 



NSRETURN 

****pCi********^ 

* IHCFCOMH 
*************** 



f CI 1 
**** 
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• Table 40. IHCFIOSH Routine Directory 



r T- 

I Routine | 

I" 



Function 



I j FCLOS 

I 

I FCNTL 

I 

jFINIT 

I 

I FREAD 



I FRITE 
L-.^ 



Checks double-buffered output data sets. 
Services device manipulation requests. 
Initializes unit and data set. 
Services read requests. 
Services write requests. 



Table 41. 



IHCDIOSE Routine Directory 

-T 



i Routine 

{■ 

DASDEF 



D/^SINIT 

I DASREAD 

DASTERM 

DASTRA 
IDASWRITE 



Function 



■I 



Processes DEFINE FILE statements: enters address of parameter lists into 
unit assignment table, checks for redefinition of direct access unit num- 
bers, and establishes addressability for subprogram IHCDIOSE within the IHC- 
FCOMH subprogram. 

Constructs unit blocks for nonopened direct access data sets, creates and 
formats new direct access data sets, and opens data control blocks for 
direct access data sets. 

Reads physical records, passes buffer pointers and buffer size to IHCFCOMH, 
and updates the associated variable. 

Checks pending input/output operations, closes direct access data sets, and 
frees main storage occupied by unit blocks. 

Determines operation type and transfers control to appropriate routine. 

Writes physical records, provides subprogram IHCFCOMH with buffer space, and 
[updates the associated variable. 
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Chart 3©. IHCIBERH Overall Logic 



****A3********* 

► FORTRAN * 

► LOAD * 

► MODULE * 



*+***B3+********* 

* * 
♦OBTAIN INTERNAL* 
♦SEQUENCE NUMBER* 

* (ISN) * 

4i*«***i|r4<*t******* 



4 * 

* CONVERT ISN * 

* TO DECIMAL * 

* FORMAT * 

* * 

:4(%4(4(it>i1c4c4iit(4(if****** 



V 
♦♦+♦♦03 *♦+**♦♦♦♦* 

* BRANCH TO * 

* IHCFCOMH TO * 

* HANDLE THE * 

* WRITING OF * 

* ERROR MESSAGE * 

*4ii«4i«**4i«4i4<*«**** 



****E3********* 

* IBEXIT RTN t 
» OF * 
!■ IHCFCOMH " 
*♦♦♦♦♦♦♦*♦+♦♦♦* 



note: 

ihciberh is entered 
via calling sequences 
generated at cokpile-time 
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• Chcirt 31. Error Monitor Overall Logic 



* INDICATE * 

* KNTHY FOR * 

* SOMKARY * 

* + 



♦SAVE REGISTERS * 

* AND LINK * 

* SAVE AREAS * 



+ MAKE INITIAL 

* CALL TO FIOCS 

* (GET BUFFER 

* ADDRESS) 



*****A3********** 

* PRINT ♦ 
+TERMINATION DUE* 

* TO DUPLICATE * 

* ENTRY ♦ 
+ MESSAGE ♦ 
♦♦+*♦♦***♦*♦**♦** 



*inn:tB3* ********* 

* * 

* PRINT * 

* MESSAGE FOR * 

* THIS ERROR ♦ 

* + 
***************** 



*****C3*+*** 



***************** 



♦ GET ADDRESS * 

♦ OF LAST ENTRY * 

♦ IN TABLE ♦ 
+ * 
***************** 



*****^^*** ******* 

* * 

* GET * 

* NUMBER OF + 

* ENTRIES * 
+ * 



+ C5 ♦-> 

* * 
**** 

♦♦♦+*C5**+***++** 

* * 

* GET NUMBER ♦ 

* OF ERRORS FOR + 

* THIS ENTRY * 
+ * 
***************** 



* 






**** 


ENTRY 


* 


YFS 


* 




FOR 




+ 


->* 


All 


SUMMARY 


* 




* 





►*+*+El +++♦+***** 



t**************** 



I/O 
ERROR 
(218) 



*+***F2 *******♦*♦ 

* * 

* GET EXIT * 
>* ADDRESS IF *- 

* SPECIFIED * 

* * 
***************** 



****£J* ******** 

* TERMINATE JOB * 

* VIA IBEXIT * 

* * 
*************** 



*****o^**** ****** 



***************** 



*****E;H********** 



*****pH*********t 

* INDICATE * 

* BUFFER AREA * 

* FOR MESSAGE * 

* MUST BE * 

* FREED ■• 
t**************** 



**** 
YES * * 
* >♦ A3 < 



+****H1*****+**** 
+ SET * 

* ENTRY SWITCH * 
*AND STORE ENTRY* 

* NUMBER + 
+ * 



. + ANY +. 

ERRORS OF . 

*.THIS TYPE.* 



. * HAS * 
.HEADING BEEN 
*. PRINTED .* 



V 
*****F5 ++*♦♦**♦*< 

* PUT ERROR ♦ 

* NUMBER AND " 
► ERROR COUNT * 
k IN MESSAGE * 
y * 
ii***************^ 



V 

*****Q^* ********* 

* * 

* PRINT LINE * 

* ♦ 

* * 
***♦*+**♦******♦* 



lF****}i5********** 



***************** 



Jl *. 




♦+***J2********** 




+ * 




* PRINT MESSAGE * 




ERROR 


*. NO 


* THAT ERROR * 




NUMBER IN 


. + 


>♦ NO. IS NOT * 


^ 


TABLE . 


* 


+ IN TABLE * 


+ . . * 




* * 


***** 


*. .* 




***************** 


♦ 32 * 


* YES 






* G2* 



V 
*****Y.X*** ******* 

* GET TABLE * 
+ ENTRY FOR * 

* THIS ERROR *- 

* NUMBER * 

* * 
***************** 



***** 
*32 * 
* Al* 



»**]<5********* 
RETURN < 

i 
k************* 
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chart 32, Error Monitor Overall Logic (cont. ) 



***** 

*32 * 
+ Al* 



.* I/O *. 
lifiROR 
EXIT ADDR 
GIVEN . 



**+**fl2****+***** 

* * 

* SET * 
->* SPECIAL EXIT *- 

* SWITCH * 

* * 
***************** 



. * CONTINUE i 

(BASED ON 

*. COUNTS) .« 



* + ** 
* 
cl *-> 



*****B2********** 

* PRINT * 

* EXECUTION ♦ 
->*TERMINATING DUE*- 

*T0 ERROR COUNT * 

* MESSAGE * 
***************** 



***** 
*31 * 
* B3* 



.* PRINT *. 
' MESSAGE *. YES 

(BASED ON .* 

'. COUNTS) .♦ 



***** 02 ********** 

* * 

* GET ADDRESS ♦ 
->* AND LENGTH OF *- 

* MESSAGE * 

* + 
***************** 



*****C3********** 

* * 

* PRINT MESSAGE * 
->*AND SET MESSAGE* 

* PRINTED * 

* INDICATION ♦ 
***************** 



PRIOT 
BUFFER 
.CONTLNTE 



***+*D2 ♦****♦♦♦** 

* * 
+ GET ADDH AND * 

>* LENGTH OF *- 
+CURRENT BUFFER * 

* * 
***************** 



*****D3********** 

* * 

* * 
->* PRINT BUFFER * 

* * 

* * 
***************** 



.* TRACEBACK +. YES 
* . REQUESTED . * 



.♦ USER *. 
->*. EXIT 

*.REgUESTFD.* 



+****G1********** 



** + **]!;2********** 

* * 

* REMOVE ONE * 
->+SAVE AREA FROM +- 

* CHAIN * 

* * 
***************** 



*****E2*****+**** 

* * 

* SET * 

* RETURN CODE TO * ■, 

: 1 

***************** ■(; 
I 



*****E3********** 

* ♦ 
*_*-*-♦_*-*-♦-*_* 

>* ♦- 

* CALL TRACE ♦ 

* * 
***************** 



**** 
*32 
♦ G2 



**** 

* * 

* GU * 

* + 
**** 



*****G3********** 



*****£!(*♦***♦**** 

* RESTORE * 
>* ONE SAVE ♦ 

* AREA TO CHAIN * 

* * 
***************** 



*****iPH* ********* 

* * **** 

* * * * 

* REINITIALIZE + >* PI * 

* FlCCS * * * 

* * ♦*** 
***************** 

**** 

* * 

* Git * — 1 



* * ] 

**** V 



* *. ***♦ 

MESSAGE *. NO * * 
PRINTED .* >* G2 * 



*************** 4 



****H1** ******** 



***************** 



*-*-*- 



-*-*-*-*-* 



♦CALL USER EXIT ♦ 
* * 

***************** 

**** 
i< * 
!._>* GU ♦ 
^ * 

**** 



*****j2*****^**** 

♦ * 

♦ TURN ♦ 

♦ OFF ENTRY ♦ 

♦ SWITCH ♦ 

♦ ♦ 
*******+****♦*+** 



V 
***K2*******^* 
* 
RETURN < 

^************* 



*****il3* ********* 
+ * 

* RESTORE USERS ♦ 
->+ REGISTERS AND * 

♦TURN OFF ENTRY ♦ 

* SWITCH * 
***************** 



****J3^^^^*+++ 

* EXIT 

* TO SPECIFIED 

* POINT 
************** 



V 
*****JH* ********* 

* PRINT ♦ 

♦ MESSAGE ♦ 

♦ INDICATING * 
*STANDARD PIXUP * 

* * 
***************** 



**** 

* * 

* G2 * 



*****H5***^^^^*** 

* PRINT + 

* MESSAGE ♦ 
->*INDICATING USER* 

* FIXUP * 

* * 
*****♦***♦+****** 



* + ** 

K * 

* G2 ♦ 

t * 

**** 
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chart 33. Alter Option Table Routine overall Logic 



*SftVS KEGISTEKS * 



*****B1 *♦***♦♦♦*♦ 



♦ »»* 



♦ CI *-> 



♦ *♦♦ 
N3XT 

*****C1 *****♦♦♦♦* 

* FINDENTKY * 
♦-*-•-*-♦-*-♦-♦-* 

* GET ADDRESS * 

* OF ENTFV FOH * 
♦THIS ERROR NO. * 
***************** 



**** 

* * 

* A2 * 

* * 
**** 



. MESSAGES TO 
*. PRINT EQ .' 



♦ YES 
I 



*****p^2********** 

* * 
.NO * SET ENTRY * 
,♦ >* TO PRINT NO * 

* MESSAGES * 

* * 
***************** 

**** 

* *• 

->* cu ♦ 

* * 
♦ ♦*♦ 



♦ 34 * 

♦ E2* 

♦ **♦* 



*****j^H* ********* 

* * 

* STORE NO. OF * 

* MESSAGES TO * 
•PRINT IN TABLE * 

* ENTRY * 
***************** 



* NUMBER * 

GT OR EQ TO 
f. 256 .* 



f * 

» INDICATE ♦ 
' PRINT ALL * 
!• MESSAGES + 
► ♦ 

I**************** 



**** 

*****Cii ********** 

* GETENTRY ♦ 
*-♦-♦-♦_♦_*_*-♦_+ 

* GET * 

* TRACEBACK * 

* INDICATION ♦ 
***************** 



.* TABLE *. 
. ♦ ENTRY 
♦. MODIFIABLE 



*****E1* ********* 

* GETENTRY * 
♦_*_*_♦_»_♦-*_»-♦ 

* GET NO. + 

* OF ERRORS * 

* ALLOWED * 
***************** 



YES .* 

*. PARAMETER 

♦OR EQ TO 



*****GX* ********* 

* * 

* STORE NO. OF ♦ 
♦ERRORS ALLOWED ♦ 
♦IN TABLE ENTRY ♦ 

* ♦ 
***************** 



.* FIRST ♦ 
->^.TIME THROUGH 
♦. (SWITCH .* 
♦ . ON) .♦ 



► H5 t 

* i 

**** 



.* *. YES 

► .CODE LT OR EQ. * ^ 

*. TO ,* 



*♦** 

♦ ♦ 

♦ GK ♦ 
+ * 

+ + ♦♦ 



NO 


.♦ SIX 


♦ . 


GT 


* 






PARAMATERS 


, * 


. + 




CODE 2 


r 


♦.SUPPLIED 


♦ 




* 




1 


♦ . .+ 








♦ , 


* 


♦ . . ♦ 




1 




*. . ♦ 


♦♦♦♦♦ 


♦ YES 




**** 




♦ L 


♦ 3it ♦ 


1 




* * 






♦ E2^ 


J 




* GH * 






♦ * 


<1 




* * 






+ 


***** 

♦ 314 ♦ 

♦ B1 + 




**** 




V 



!>♦♦*♦ PH *♦♦ + *♦+♦* + 




*****QH* ********* 

♦ GETENTRY ■» 
*-*-*-*-*-*-*-*-* 

* GET USER * 

♦ ADDRESS * 

* 4 
***************** 



3T OR. 
256. ♦ 



*****il2** ******** 

♦ SET ♦ 
♦ERROR COUNT TO ♦ 

->♦ ALLOW TO ZERO ♦ 

♦ (ALLOW ALL * 

♦ ERRORS) ♦ 
***************** 



♦-*-+-*-♦-♦-*-♦-* 
+ GET NUMBER OF ♦ 

♦ MESSAGES TO ♦ 

♦ PRINT * 
♦♦♦♦♦♦*♦♦♦♦♦•♦♦♦♦ 



.♦MESSAGES TC+ 
. PRINT LT OR 
♦. EQ TO .♦ 



*****JH* ********* 
t * 

* STORE ADDRESS ♦ 
H IN TABLE ♦ 
► ENTRY ♦ 
t * 

^**** ************ 



*****-E5 ********** 

* * 

* INDICATE ♦ 
>♦ TRACEBACK ♦ 

♦ REQUESTED ♦ 

♦ ♦ 
***************** 



***** 
♦33 ♦ 
♦ H5 + 



V 



r 

♦ ♦♦4 
I: 

♦ CI 

♦ ♦♦♦ 



♦♦♦♦♦H5^ ♦♦♦♦♦♦♦♦♦ 

♦ UPDATE ERR ♦ 

♦ NO. BY ONE ♦ 

♦ (TURN FIRST ♦ 
+ TIME THROUGH ♦ 

♦ SWITCH ON) ♦ 
***************** 



V 

. ♦. 

J5 +. 

. ♦ ERROR ♦. 

. * NUMBER GT ♦. 

.MAXIMUM TO BE. 

*. CHANGED .♦ 



♦ ♦♦♦ + 

♦ 31» ♦ 

♦ E2^ 



♦ ♦♦♦ 
3 ♦ * 
—>* A2 t 

* 4 

♦ ♦♦♦ 



. ♦ FIRST ♦ , 

TIME 

THROUGH 

.SWITCH ON. 
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Chart 34- Alter Option Table Routine Overall Logic (cont. ) 



***** 

*3K ♦ 
* Al* 



*. ERROR 212 •* 


♦. . ♦ 


*. . * 


*, , * 


♦ NO 


**** 




♦ 34 * 




* Bl *-> 




* * 




**** 




* 


*****B1* *♦♦*♦**♦♦ 


* GETENTRY * 


♦-*_♦-*-♦-*_*_♦-* 


* GET UPPER * 


♦RANGE OF NO. TO* 


♦ BE CHi 


VNGED * 



***************** 



**** *;^2 ********* * 

* GETENTRY ♦ 
*-*-*-*-*-*-*-*-* 

'+ GET CONTROL * 

* CHARACTER ♦ 

* INDICATION * 
***************** 



*****B2 ********** 

* INDICATE NO * 

* CONTROL * 
♦CHARACTER TO BE* 

* SUPPLIED * 

* * 
***************** 



♦****C1* ********* 


C2 


* 


* TURN ON 


* 


. * 


* SWITCH 


* 


NO .» EQUALS 
r — *. C0DE=1 


♦ INDICATING 


* 


* FIRST TIME 


* 


*. 


* THROUGH 


« 


♦ . 


***************** 


V +. .♦ 








**** * Y 








* * 










* E2 * 










* * 










***♦ 





*****Q1********** 

* * 

* STORE UPPER * 

* RANGE AS * 

* MAXIMUM TO BE * 

* CHANGED * 
***************** 



***** 
*33 * 
* H5* 

♦ * 



*SAVE REGISTERS * 



***************** 



*****B3********** 



***************** 



♦_*_*-*-*-*-*-*-* 

* GET * 

* ADDRESS OF + 

* TABLE ENTRY * 
***************** 



*****D3********** 



♦SAVE REGISTERS ♦ 



***************** 



»****BU ********** 



***************** 



*****CH* ********* 

* FINDENTRY * 
*-*-*-*-*-♦-*-*-* 

* GET ♦ 

* ADDRESS OF ♦ 

* TABLE ENTRY ♦ 
***************** 



♦ CONTROL ♦ 


* GET ADDRESS ♦ 


.♦ ENTRY +. NO 


♦CHARACTER TO BE^ 


+ OF WHERE TO ♦ 


*. MODIFIABLE . *- 


-.^ 


♦ SUPPLIED ♦ 


+ SAVE ENTRY * 


*. . * 




* * 


* * 


*. .♦ 




***************** 


***************** 


*. .* 


'■ 










* YES 


**** 


**** 












* 


*3H * 












* E2 


* E2 *-> 












* 


* * 












«*** 


**** 














FINISHED V 


7 


7 




*****E2********** 


♦****E3*+******** 


♦ ****E>4^^******** 




* * 


* * 


♦ GET * 




* TURN OFF * 


+ MOVE * 


♦ ADDRESS OF ♦ 




* SWITCHES + 


♦ TABLE ENTRY * 


♦ WHERE TO ♦ 




* * 


* * 


♦ RESTORE TABLE * 




* ♦ 


+ + 


* ENTRY FROM * 




***************** 


***************** 


***************** 








**** 












* * 












l~>* E2 * 












* * 












**** 














7 




V 




*****FH* ********* 




****F2***^^^^+^ 




* * 




* * 




* * 




♦ RETURN * 




* RESTORE TABLE * 




* * 




♦ ENTRY * 




*************** 




* * 
***************** 

+ *** 

* * 
•— >* E2 * 

* * 














**♦* 
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Chart 35. Alter Option Table Routine Overall Logic (cont. ) 



Al 



*. 



. * ERROR * . 
.* NO. LT OR ♦. YES 

*. EQ TO FIRST .* 

♦ . TABLE . * 
♦.ENTRY.* 
+ . . * 
♦ NO 



. +ERR NO. GT * 

(•.NO, OF TABLE 

♦. ENTRIES .* 



*****A2 ♦**+♦****♦ 

* ♦ 

* SET * 
->* UP FOR ERROR * 

* NO. 902 * 

* * 



*****B2**** ****** 

* WRITE * 

*-*-*-*r*-*-*-*-* 

* WRITE MESSAGE * 

* 902 * 
*♦**♦**♦**♦***♦** 



ENTRY . ♦ . 








A3 ♦. 








. * ♦ 








. * LAST 


+ 


YES 




* . PARAMETER 




*_ 


— ^ 


*. GOTTEN 


* 




*. . * 






***** 


*. . * 






♦ 3lt * 


* NO 






+ E2* 










♦ * 










* 


. 








*itt«*+B3>t<*'*"i'4'* + **4' 




* 




^ 




* UPDATE 




* 




♦ TO NEXT 




* 




♦ PARAMETER 




* 





*****♦*♦**♦***++* 



«****C1********** 
« ♦ 

* GET * 
X TABLE ENTRY * 

* ADDR * 

* * 

:(<4t******4:******** 



***** 
♦34 ♦ 

* E2* 
♦ * 



***+*C3********** 



urn******* 



Dl *. 

.* TABLE ♦. ****D2********* 

, * ENTRY * . YES * * 

. MODIFIABLE .* >♦ RETURN * 

*. .* A * ■• 

******t4i4<******* 

NO 



V 

****D3********* 
^ * 

>• RETURN * 

¥ 4 

**♦*+♦+*+*♦+*** 



l>**«*Fl«4>i|i****1i + * 



***************** 



*****G2*** ******* 

* * 

* MAKE ♦ 
->*INITIALIZATION ♦ 

* CALL TO FIOCS * 

* * 
***************** 



*****H1 ********** 
+ * 

+ PUT ERROR * 

* NO. INTO * 

* MESSAGE * 

* * 
***************** 



t****Jl* ********* 

* * 

* WRITE * 

* MESSAGE VIA * 
'* FIOCS * 

* * 
***************** 



V 
i'***Kl********* 

RETURN * 

K ************** 
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APPENDIX F: ADDRESS COMPUTATION FOR ARRAY ELEMENTS 



Data references in the form of sub- 
scripted variable expressions in FORTRAN 
are converted into object code that 
includes address arithmetic and indexed 
references to main storage addresses. 
Since the conversion involves all phases of 
the compiler, a summary of the method is 
given here. 



Consider an array A of n dimensions 
whose element length is L, and whose dimen- 
sions are Dl, D2, D3, ...,Dn. If such an 
array is assigned main storage starting at 
the address Pll, then the element A(J1, J2, 
J3,...,Jn) is located at: 



L 


2,J1 


SLL 


2r logaL 


L 


1, J2 


M 


0,L*D1 


AR 


2,1 


L 


1,J3 


M 


0,D1*D2*L 


AR 


2,1 



P = Pll + (J1-1)*L + (J2-1)*D1*L + 

(J3-1)*D1*D2*L + ... + (Jn-1)*D1*D2*D3* 
...*D(n-l)*L 



This may be expressed as : 

P = POO + Jl+L + J2*(D1*L) + J3*(D1*D2*L) 
+ ... + Jn*(Dl*D2*D3* ... ♦DCn-D+L) 



L l,Jn 

M 0,Dl*D2*...*D(n-l) 

AR 2,1 



where : 



POO = Pll - (L+Dl+L + D1+D2+L + 
D1+D2* ... ♦D(n-1)*L) 



Absorption of Constants in Subscript 
Expressions 



For fixed dimensioned arrays, the quan- 
tities Dl+L, D1+D2+L, D1*D2*D3*L, ... , 
which are referred to as dimension factors, 
are computed at compile time. The sum of 
these quantities, which is referred to as 
the span of the array, is also computed at 
compile time. (Phase 15 assigns to an 
array a relative address equal to its actu- 
al relative address minus the span of the 
array. ) 



In the object code, P is finally formed 
as the sum of a base register^ an index 
register, and a displacement. The phase 15 
segment CORAL associates an address con- 
stant with each fixed dimensioned array 
such that Pa<P00<Pa+4095, where Pa is the 
address inserted into the address constant 
at program fetch time. The effective 
address is then formed using a base regis- 
ter containing the address constant, a dis- 
placement equal to POO - Pa, and an index 
register, which contains the result of a 
computation of the form: 



Subscript expressions may include con- 
stant parts whose contribution to the final 
effective address is computed at compile 
time. For example. 



B(I-2, J+4,3*5-(L+7)-6) 



would usually be treated in such a way that 
the effect of the 2, the 4, and the 6 would 
be absorbed into the displacement at com- 
pile time. 

Consider an example of the form 



A(J1+K1, J2+K2, ... ,Jn+Kn), 



where : 

A is a fixed dimensioned array 

Kl, K2, ..., Kn are integer constants 
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Phase 15 will insert the quantity 



K1*L + K2*CD1*L) + K3*(D1*D2*L) + 
... + Kn(Dl*D2* ... ♦D(n-1)*L) 



add text entry is inserted to alter the 
index register immediately before the 
reference. 



into the displacement (DP) field of the 
corresponding subscript or load address 
text entry. The constants will not other- 
wise be included in the subscript expres- 
sion. When phase 25 generates machine 
code, the contents of the DP field are 
added to the displacement. To ensure that 
the resultant expression lies within the 
range of to 4095, phase 20 performs a 
check. If the result is not within the 
range, a dictionary entry is reserved for 
the result of the addition, and a suitable 



Arrays as Parameters 



When an array is used as an argument, 
the location of its first element, Pll, is 
passed in the parameter list. The prologue 
of the called subroutine contains machine 
code to compute the corresponding POO loca- 
tion. When an array has variable dimen- 
sions, no constant absorption takes place 
and the dimension factors are computed for 
each reference to the array. 



222 



APPENDIX G: COMPILER STRUCTURE 



The FORTRAN (H) compiler is structured 
in a planned overlay fashion. A planned 
overlay structure is a single load module, 
created by the linkage editor in response 
to overlay control statements. These 
statements, a description of the planned 
overlay structure, and instructions in 
specifying such a program structure are 
presented in the publication IBM Svstem/360 
Operating System; Linkage Editor . The 
processing performed by the linkage editor 
in response to overlay control statements 
is described in the publication IBM System/ 
3 60 O perating System; Linkage Editor, Pro- 
gram Logic Manual . 

The compiler's planned overlay structure 
consists of 13 segments, one of which is 
the root. The root segment contains the 
FSD and includes the processing units 
(e.g., the compile-time input/output rou- 
tines) and data areas (e.g., communication 
region) that are used by two or more 
phases. The root segment remains in main 



storage throughout the execution of the 
compiler. 

Each of the remaining 12 segments con- 
stitutes a phase or a major portion of a 
phase. Phase segments are overlaid as com- 
piler processing requires the services of 
another segment. 

Figure 62 illustrates the compiler' s 
planned overlay structure. In the illus- 
tration, each segment is identified by a 
number. Segments that originate from the 
same horizontal line overlay each other as 
needed. The illustration also indicates 
the approximate size (in bytes) of each 
segment. 

The longest path^ of this structure is 



*-A path consists of a segment, all segments 
between it and the root segment, plus the 
root segment. 



I 



(18.6)^ 



(30.2) 



(62.4) 



4 - 15/20 



(6.1) 



(9.7) 



(20,9) 



(23.4) 



(33.8) 



(56.2) 



'The number in parentheses times 1,000 equals the approximate segment length. 



(9.9) 



(21.5) 



(56.2) 



(53.7) 



• Figure 62. Compiler Overlay Structure 
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I formed by segments 1, 4, 7, and 10 because, 
when they are in main storage, the compiler 
requires approximately 81, 000 bytes. Thus, 
the minimum main storage requirement for 

I the compiler is approximately 89,000 bytes. 



The linkage editor assigns the relocat- 
able origin of the root segment (the origin 
of the compiler) at 0. The relocatable 
origin of each segment is determined by 
summing the length of all segments in the 
path. For example, the origin of segment 
10 is equal to the length of segment 1 plus 
the length of segment 4 plus the length of 
segment 7, 



The segments that constitute each phase 
of the compiler are outlined in Table 42. 
The remainder of this appendix is devoted 
to a discussion of the segments of the com- 
piler's planned overlay structure. 



Table 42. Phases and Their Segments 

r— T 1 

(Phase I Segment (s) Constituting Phase | 
j. ^ ^ 

I Phase 10 1 Segment 2 
JXREF I Segment 3 
(Phase 15 1 Segments 4, 
I Phase 20 1 Segments 4, 
I Phase 25 1 Segment 13 
(Phase 30 1 Segment 12 
X 



5, 
7, 



8, 9, 10, 11 



I- 

( Note; Segment 4 is loaded whenever 
(phases 15, 20, or 30 are loaded. It con- 
I tains data areas used by 15 and 20. 

L_. 



Segment 1 ; This segment is the root seg- 
ment of the compiler's planned overlay 
structure. Segment 1 is the FSD. It has a 
relocatable origin at and is not overlaid 
by other compiler phases. The composition 
of segment 1 is illustrated in Table 43. 



Table 43. Segment 1 Composition 

r T 

(control Section(Entry Point (s) 



lEKATB 

lEKAAOl 

ADCON-IEKAAD 

PUTOUT-IEKAPT 

lEKATM 

DCLIST-IEKTDC 
AFIXPI-IEKAFP 
lEKAAOO 

lEKFIOCS 
lEKFCOMH 
lEKTLOAD 

ERCOM-IEKAER 
lEKAAA 



lEKATB 
PAGEHEAD 

PUTOUT 

PHAZSS, PHASE, TST, PHASS, 

TSP,TOOT,TIMERC 
lEKTDC 

FIXPI , AFIXPI , FIXPI# 
lEKAGC, ENDFILE, IEKAA9 , 

lEKIORTN 
FIOCS#,FIOCS 
IBCOM#, IBCOM 
lEKUSD, ESD, TXT, lEKTXT, 

RLD, lEKURL, lEND, lEKUND 



Table 44. Segment 2 Composition 



r T 

Control Section(Entry Point (s) 
^ + ^ 



STALL- lEKGST 

XSUBPG-IEKCSR 

LABTLU-IEKCLT 

XARITH-IEKCAR 

DSPTCH-IEKCDP 

XIOPST-IEKDIO 

GETCD-IEKCGC 

CSORN-IEKCCR 

XTNDED-IEKCTN 

lEKKOS 

XIOOP-IEKCIO 

PUTX-IEKCPX 

XDATYP-IEKCDT 

GETWD-IEKCGW 

XCLASS-IEKDCL 

FORMAT- lEKTFM 

XSPECS-IEKCSP 

XGO-IEKCGO 

XDO-IEKCDO 

PHIO-IEKCAA 

lEKXRS 



lEKGST 

lEKCSR 

lEKCLT 

lEKCAR 

lEKCDP, lEKCIN 

lEKDIO 

lEKAREAD 

lEKCCR, IEKCS3 , lEKCSl , 

IEKCS2, lEKCLC 
lEKCTN 
lEKKOS 
lEKCIO 
lEKCPX 
lEKCDT 

lEKDCL 
lEKTFM 
lEKCSP 
lEKCGO 
lEKCDO 



Segment 2 ; This segment is phase 10. The 
origin of the segment is immediately fol- 
lowing segment 1. At the completion of 
phase 10 operation, segment 2 is overlaid 
by segment 3 if the XREF option was chosen 
or by segment 4 if the option was not cho- 
sen. The composition of segment 2 is 
illustrated in Table 44. 



Segment 3 ; This segment contains subrou- 
tine XREF-IEKXRF. Its origin is immediate- 
ly following segment 1. If the XREF option 
is chosen, segment 3 overlays segment 2. 
If the XREF option is not selected, segment 
3 is not used and segment 2 is overlaid by 
segment 4 . 
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Segment 4 : This segment is considered a 
portion of both phases 15 and 20. It con- 
tains data areas used by both phases. The 
origin of segment 4 is immediately follow- 
ing segment 1. Segment 4 is overlaid by 
segment 13. The composition of segment 4 
is illustrated in Table 45. 



Segment 6 ; This segment is a portion of 
phase 15. It contains the subroutines that 
implement the CORAL f\anctions of the phase. 
The origin of segment 6 is immediately fol- 
lowing segment 4. Segment 6 overlays seg- 
I ment 5 and is overlaid by segment 7. The 
composition of segment 6 is illustrated in 
Table 47. 



Table 45. Segment 4 Composition 

r T T 

j Control Section! Entry Point (s) | 

I \ ^ • Table 47. Segment 6 Composition 

JCMAJ0R-IEKJA2 | | | f 

JRMAJ0R-IEKJA4 j j j Control Section | Entry Point (s) 

L X J ^ 4 



Segment 5 : This segment is a portion of 
phase 15. It contains subroutines that 
implement the PHAZ15 functions of that 
phase which are arithmetic translation, 
text blocking, and information gathering. 
The origin of segment 5 is immediately fol- 
lowing segment 4. Segment 5 is overlaid by 
segment 6. The composition of segment 5 is 
illustrated in Table 46. 



• Table 46. Segment 5 Composition 

r T 

I Control Section I Entry Point (s) 



I lEKLTB 

I LOOKER- lEKLOK 

JGENRTN-IEKJGR 

jFUNRDY-IEKJFU 

ICNSTCV-IEKKCN 

lOPlCHK-IEKKOP 

I SUBMULT-IEKKSM 

IPHA215-IEKJA 

1 BLTNFN-IEKJBF 

I STTEST-IEKKST 

JRELOPS-IEKKRE 

JFINISH-IEKJFI 

IDFUNCT-IEKJDF 

JMATE-IEKLMA 

jANDOR-IEKJAN 

i cpltst-iekjcp 

junary-iekkun 

idump15-iekler 

jparen-iekkpa 

jgener-ieklgn 

jaltran-iekjal 

[txtlab-ieklab 

itxtreg-ieklrg 

jsubadd-iekksa 

1PH15-IEKJA1 
I IEKJA3 



lEKJGR 

lEKJFU 

lEKKCN 

lEKKOP, lEKKNG 

lEKKSM 

lEKJA 

lEKJBF 

lEKKST 

lEKKRE 

lEKJFI 

lEKJDF, lEKKPR 

lEKLMA 

lEKJAN, lEKKNO 

lEKJCP, lEKJMO 

lEKKUN, lEKKSW, lEKJEX 

lEKLER 

lEKKPA 

lEKLGN 

lEKJAL 

lEKLAB 

lEKLRG 

lEKKSA 



JDFILE-IEKTDF 

INLIST-IEKTNL 

JCORAL-IEKGCR 

jNDATA-IEKGDA 

JEQVAR-IEKGEV 

ICMSIZE-IEKGC2 

IDATOUT-IEKTDT 

I lEKGAl 



I lEKTDF 
I lEKTNL 
I lEKGCR 
I lEKGDA 
I lEKGEV 
jIEKGCZ 
I lEKTDT 



._J 



Segment 7 : This segment is a portion of 
phase 20. It contains the controlling sub- 
routine of that phase, the loop selection 
routine, and a number of frequently used 
utility subroutines. The origin of segment 
7 is immediately following segment 4. Seg- 
ment 7 overlays segment 6. The composition 
of segment 7 is illustrated in Table 48. 



• Table 48. Segment 7 Composition 



r T 

I Control Section I Entry Point (s) 
f 



ILPSEL-IEKPLS 

JIEKARW 

I TARGET- lEKPT 

JGETDIK-IEKPGK 

I 

I lEKPOP 



I lEKPLS 

I 

I lEKPT 

I lEKPGK, lEKPGC, lEKPIV, 

|IEKPFT,IEKPOV 

I 



Segment 8 ; This segment is a portion of 
phase 20. It consists of the subroutines 
that determine (1) the back dominator, back 
target, and loop number of each source 
module block, and (2) the busy-on-exit 
data. Segment 8 is executed only if the 
0PT=2 path through phase 20 is followed. 
The segment is executed only once and is 
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overlaid by segment 9. The origin of seg- 
ment 8 is immediately following segment 7. 
The composition of segment 8 is illustrated 
in Table 49. 



• Table 49, Segment 8 Composition 

r T 

(Control Section I Entry Point (s) 



h 

ISRPRIZ-IEKQAA 

JTOPO-IEKPO 

I BAKT-IEKPB 

JBIZX-IEKPZ 

I lEKPBL 

L 



j lEKQAA, lEKQAB 
I lEKPO 
I lEKPB 
I lEKPZ 



Segm ent 9 ; This segment is a portion of 
phase 20. It contains subroutines that 
perform common expression elimination and 
strength reduction as well as the major 
portion of the utility subroutines used 
during text optimization. Segment 9 is 
executed only if the 0PT=2 path through 
phase 20 is specified. The origin of seg- 
ment 9 is immediately following segment 7, 
During the course of optimization, segment 
9 overlays segment 8 and is overlaid by 
segment 10 after all module loops have been 
text-optimized. The composition of segment 
9 is illustrated in Table 50. 



tines used by them, and the subroutine that 
calculates the size of each text block and 
determines which text blocks can be 
branched to via RX-format branch instruc- 
tions. Segment 10 is executed in the opti- 
mized paths through phase 20. The origin 
of segment 10 is immediately following seg- 
ment 7. The composition of segment 10 is 
illustrated in Table 51. 



Table 51. Segment 10 Composition 



J. ^ 

[Control Section 1 Entry Point (s) 




i. _ _^_ 


_j._ « « _ 




[BLS-IEKSBS 


1 lEKSBS 




ICXIMAG-IEKRCI 


1 lEKRCI 




IBKPAS-IEKRBP 


1 lEKRBP 




IGLOBAS-IEKRGB 


1 lEKRGB 




IFWDPSI-IEKRFI 


1 lEKRFl 




ILOC-IEKRLI 


1 




IFCLT50-IEKRFL 


j lEKRFL, lEKRRL, lEKRTF 




ISTXTR-IEKRSX 


1 lEKRSX 




IFWDPAS-IEKRFP 


1 lEKRFP 




1 SEARCH- lEKRS 


1 lEKRS 




1 REGAS-IEKRRG 


1 lEKRRG 




IFREE-IEKRFR 


1 lEKRFR 




IBKDMP-IEKRBK 


1 lEKRBK 




1 


_JL -^ 





Table 50. Segment 9 Composition 

r T 

{Control Section! Entry Point (s> 



I i KORAN- lEKQKO 
IWRITEX-IEKQWT 
I CIRCLE- lEKQCL 
I PERFOR-IEKQPF 

I JTYPLOC-IEKQTL 
JXSCAN-IEKQXS 
JXPELIM-IEKQXM 
JMOVTEX-IEKQMT 
JCLASIF-IEKQCF 
JBACMOV-IEKQBM 
I REDUCE- lEKQSR 
JSUBSUM-IEKQSM 



lEKQLO 

lEKQWT 

lEKQCL, lEKQF 

lEKQPF 

lEKQTL 

lEKQXS, lEKQYS, lEKQZS 

lEKQXM 

lEKQMT, lEKQDT 

lEKQCF, lEKQPX, lEKQMF 

lEKQBM 

lEKQSR 

lEKQSM 



Segment 10; This segment is a portion of 
phase 20. It contains full register 
assignment subroutines, the utility subrou- 



Seqment 11 ; This segment is a portion of 
phase 20. It consists of the subroutines 
that perform basic register assignment. 
Segment 11 is executed only in the OPT=0 
path through phase 20. The origin of seg- 
ment 11 is immediately following segment 7. 
Segment 11 does not overlay any other seg- 
ment in phase 20, nor is it overlaid by 
another segment in phase 20. The composi- 
tion of segment 11 is illustrated in Table 
52. 



Table 52. Segment 11 Composition 

r T 1 

(Control Section I Entry Point (s) | 

^ + ^ 

JSSTAT-IEKRSS j lEKRSS j 

JTALL-IEKRLL | lEKRLL | 

ISPLRA-IEKRSL | lEKRSL | 

L J. J 
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s egment 12 ; This segment is phase 30. The 
origin of segment 12 is immediately follow- 
ing segment 4. Segments 4 and 12 overlay 
segment 13, if errors are encoiantered dur- 
ing the processing of previous phases. The 
composition of segment 12 is illustrated in 
Table 53. 



Table 53. Segment 12 Composition 

I T 1 

I Control SectionI Entry Point (s) | 

^ + „ ^ 

IMSGWRT-IEKP31 j IEKP31 j 

IIEKP30-IEKP30 | j 

L X J 



# Table 54. Segment 13 Composition 

r T 

(Control Section I Entry Point (s) 



Segment 13 ; This segment is phase 25. The 
origin of segment 13 is immediately follow- 
ing segment 1. Segment 13 overlays segment 
4. The composition of segment 13 is illus- 
trated in Table 54. 



k 

IMAINGN2-IEKVM2 

I PACKER- lEKTPK 

ILABEL-IEKTLB 

I RETURN- lEKTRN 

JFNCALL-IEKVFN 

JGOTOKK-IEKWKK 

JLISTER-IEKTLS 

JSTOPPR-IEKTSR 

JENTRY-IEKTEN 

JCGEN-IEKWCN 

JBRLGL-IEKVBL 

JIOSUB-IEKTIS 

I PROLOG- lEKTPR 

JMAINGN-IEKTA 

JTENTXT-IEKVTN 

II0SUB2-IEKTI0 

jEND-IEKUEN 

I EPILOG- lEKTEP 

I lEKGMP 

jADMDGN-IEKVAD 

JTSTSET-IEKVTS 

JPLSGEN-IEKVPL 

JSUBGEN-IEKVSU 

I UNRGEN-IEKVUN 

IBITNFP-IEKVFP 

]FAZ25-IEKP25 



IEKVM2 
lEKTPK 
lEKTLB 
lEKTRN 
lEKVFN 
lEKWKK 
lEKTLS 
lEKTSR 
lEKTEN 

lEKVBL 

lEKTIS 

lEKTPR 

lEKTA 

lEKVTN 

lEKTIO 

lEKUEN 

lEKTEP 

lEKVAD 
lEKVTS 
lEKVPL 
lEKVSU 
lEKVUN 
lEKVFP 
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APPENDIX H; DIAGNOSTIC MESSAGES 



The messages produced by the compiler 
are explained in the publication IBM 
System/ 360 Operating Syste m : FORTRAN I V (G 
and H) Programmer's Gui de. Each message is 
identified by an associated niunber. The 
following table associates a message number 
with the phase and siibroutine in which the 
corresponding message is generated. 



As part of its processing of errors, 
whenever the compiler encounters an error 
that is serious enough to cause deletion of 
a compilation, it prints out: COMPILATION 
DELETED. (For a more detailed explanation, 
refer to Appendix D of the aforementioned 
publication. ) 



f— — — — — ~- —""If""' ""— — ""■"— ~ 1" — 1 




1 Routine in Which) Phase in Which] 


1 Message 


Message Number | Message Number] 


1 Number 


Is Generated | Is Generated j 


1 . J 


L « . J. J 


1 — „. ^ 


r — "■ 1 1 


1 IEK002I 


XCLASS-IEKDCL ( j 


1 IEK003I 


XARITH-IEKCAR | | 


1 IEK005I 


XARITH-IEKCAR | | 


1 IEK006I 


XARITH-IEKCAR, | | 




LABTLU-IEKCLT, | | 




DSPTCH-IEKCDP, | | 




XIOOP-IEKCIO, 1 1 




XCLASS-IEKDCL | j 


1 IEK007I 


XARITH-IEKCAR | | 


1 IEK008I 


CSORN-IEKCCR | | 


1 IEK009I 


CSORN-IEKCCR | | 


1 lEKOlOI 


CSORN-IEKCCR | | 




1 PHASE 10 1 


1 lEKOllI 


XARITH-IEKCAR | | 


1 IEK012I 


CSORN-IEKCCR# | | 


1 IEK013I 


XARITH-IEKCAR, | | 




PUTX-IEKCPX, 1 1 




CSORN-IEKCCR, j j 




XCLASS-IEKDCL | j 


1 IEK014I 


XDATYP-IEKCDT, | | 




XSPECS-IEKCSP 1 j 


1 IEK016I 


XGO-IEKCGO 1 1 


1 IEK017I 


XGO-IEKCGO 1 1 


1 IEK019I 


XGO-IEKCGO 1 1 


1 IEK020I 


XGO-IEKCGO 1 1 


1 IEK021I 


XGO-IEKCGO 1 I 


1 IEK022I 


XGO-IEKCGO 1 1 


1 IEK023I 


XTNDED-IEKCTN | | 



r T T 1 




Routine in Which {Phase in Which | 


1 Message 


Message Number {Message Number j 


1 Number 

L 


Is Generated | Is Generated j 

L J 


r 


r 1 


1 IEK024I 


XTNDED-IEKCTN j | 


1 IEK025I 


XTNDED-IEKCTN | | 


1 IEK026I 


XTNDED-IEKCTN | | 


1 IEK027I 


XIOPST-IEKDIO 1 1 


1 IEK028I 


XIOPST-IEKDIO 1 1 


1 IEK030I 


XDO-IEKCDO 1 1 


1 IEK031I 


XDO-IEKCDO 1 1 


] IEK03UI 


DSPTCH-IEKCDP | j 


1 IEK035I 


DSPTCH-IEKCDP | | 


] IEK036I 


DSPTCH-IEKCDP | | 




I PHASE 10 I 


1 IEK039I 


XTNDED-IEKCTN | j 


1 lEKOUOl 


XCLASS-IEKDCL | | 


1 IEK046I 


XSPECS-IEKCSP 1 1 


] IEK0U7I 


XARITH-IEKCAR, | | 




XDATYP-IEKCDT j | 


] IEK050I 


XARITH-IEKCAR | | 


] IEK052I 


DSPTCH-IEKCDP | | 


1 IEK053I 


XARITH-IEKCAR, | | 




DSPTCH-IEKCDP | j 


1 IEK056I 


XSUBPG-IEKCSR | | 


1 IEK057I 


XSUBPG-IEKCSR | | 


1 IEK058I 


XSUBPG-IEKCSR | | 


1 IEK059I 


XSUBPG-IEKCSR | | 



L X X J 
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r • 

i Message 

1 N\imber 
1 


r T n 

Routine in Which | Phase in Which | 
Message Number | Message Number | 

Is Generated | Is Generated j 

4. J 


r 

1 IEK060I 


T 1 

XARITH-IEKCAR, | | 
DSPTCH-IEKCDP | j 


1 IEK062I 


STALL-IEKGST | | 


1 lEKOem 


XTNDED-IEKCTN | | 


1 IEK065I 


XTNDED-IEKCTN | | 


1 IEK066I 


XTNDED-IEKCTN | | 


1 IEK067I 


XTNDED-IEKCTN | | 


1 IEK069I 


XSPECS-IEKCSP 1 1 


1 IEK070I 


XSPECS-IEKCSP 1 1 


1 IEK072I 
1 IEK073I 


XSPECS-IEKCSP 1 1 

1 PHASE 10 1 

XSPECS-IEKCSP 1 1 


1 IEK07UI 


XSPECS-IEKCSP 1 1 


1 IEK075I 


XSPECS-IEKCSP 1 1 


1 IEK076I 


XTNDED-IEKCTN | | 


1 IEK077I 


XTNDED-IEKCTN | j 


1 IEK078I 


XTNDED-IEKCTN | | 


1 IEK079I 


XTNDED-IEKCTN | | 


1 IEK080I 


XTNDED-IEKCTN | | 


1 IEK081I 


XTNDED-IEKCTN | | 


1 IEK082I 


XTNDED-IEKCTN | J 


1 IEK083I 


XTNDED-IEKCTN | | 


1 IEK08UI 


XTNDED-IEKCTN | | 


1 IEK086I 


XSPECS-IEKCSP 1 1 


1 IEK087I 


XSPECS-IEKCSP 1 ! 


1 IEK090I 


DSPTCH-IEKCDP | | 


1 IEK091I 


DSPTCH-IEKCDP | | 


1 IEK092I 


XDATYP-IEKCDT | | 


1 IEK093I 


XDATYP-IEKCTN | | 


1 IEK094I 


XDATYP-IEKCTN | | 


1 IEK095I 
1 


XDATYP-IEKCTN | | 


1 IEK096I 


XDATYP-IEKCTN | | 



r 1 

1 Message 
I Number 


T 1 

Routine in Which | Phase in Which | 
Message Number j Message Number} 
Is Generated j Is Generated \ 

1 ^ 


[. 

1 IEK097I 


XTNDED-IEKCTN | | 


1 IEK098I 


XTNDED-IEKCTN | | 


1 IEK099I 


XTNDED-IEKCTN | | 


1 lEKlOOI 


XTNDED-IEKCTN | | 


1 lEKlOlI 


XDO-IEKCDO 1 1 


1 IEK102I 


XIOPST-IEKDIO 1 1 


1 lEKlOm 


XIOPST-IEKDIO 1 1 


1 IEK109I 


XIOPST-IEKDIO 1 1 


1 lEKllOI 


XIOPST-IEKDIO 1 1 


1 lEKlllI 
1 IEK112I 


XIOPST-IEKDIO 1 1 

I PHASE 10 1 

XGO-IEKCGO, 1 I 

XSPECS-IEKCSP 1 1 


1 IEK113I 


XIOPST-IEKDIO 1 1 


1 IEK115I 


XIOPST-IEKDIO 1 1 


1 IEK116I 


XDO-IEKCDO 1 1 


1 IEK1X7I 


DSPTCH-IEKCDP | | 


1 IEK120I 


DSPTCH-IEKCDP | | 


1 IEK121I 


XDATYP-IEKCDT | | 


1 IEK122I 


XDATYP-IEKCDT | | 


1 IEK123I 


XDATYP-IEKCDT | | 


1 IEK124I 


XDATYP-IEKCDP j | 


1 IEK125I 


XDATYP-IEKCDP | | 


1 IEK129I 


XDATYP-IEKCDT | | 


1 IEK132I 


XDATYP-IEKCDT | | 


1 IEK133I 


XDO-IEKCDO 1 1 


1 IEK134I 


XDO-IEKCDO 1 1 


1 IEK135I 


XDO-IEKCDO 1 1 


1 IEK136I 


XDO-IEKCDO 1 1 


1 IEK137I 


XDO-IEKCDO 1 1 


1 IEK138I 


XDO-IEKCDO I 1 



L ± ± J 
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r 

1 Message 

1 Number 
L_,_ 


r T • 1 

Routine in Which | Phase in Which) 

Message Number | Message Number) 

Is Generated j Is Generated ) 

_j. ji 


1 IEK139I 


DSPTCH-IEKCDP, 
XSPECS-IEKCSP, 
XDATYP-IEKCDT, 
XTNDED-IEKCTN 


T T 


1 lEKlUOI 


DSPTCH-IEKCDP, 
XIOPST-IEKDIO 




1 IEK141I 


XIOPST-IEKDIO 




1 lEKlUai 


DSPTCH-IEKCDP 




1 lEKlUm 


DSPTCH-IEKCDP 




1 IEK145I 


DSPTCH-IEKCDP 




1 IEK146I 


DSPTCH-IEKCDP 




1 IEK1U7I 


DSPTCH-IEKCDP 




1 lEKlUei 


XSPECS-IEKCSP 




1 IEK149I 


XIOPST-IEKDIO 




1 IEK150I 


XSPECS-IEKCSP 




1 IEK151I 
1 IEK152I 


XSPECS-IEKCSP 
XSUBPG-IEKCSR 


) PHASE 10 j 


1 IEK153I 


XARITH-IEKCAR 




1 IEK156I 


XIOOP-IEKCIO 




1 IEK157I 


XARITH-IEKCAR 




1 IEK158I 


XDO-IEKCDO 




1 IEK159I 


XIOPST-IEKDIO 




j IEK160I 


XIOOP-IEKCIO, 
XDO-IEKCDO 




1 IEK161I 


XIOOP-IEKCIO 




1 IEK163I 


XDO-IEKCDO 




1 IEK165I 


XIOOP-IEKCIO 




1 IEK166I 


XIOOP-IEKCIO 




1 IEK167I 


XARITH-IEKCAR, 
XSPECS-IEKCSP, 
XIOPST-IEKDIO, 
DSPTCH-IEKCDP, 
XSUBPG-IEKCSR, 
XDO-IEKCDO 




1 IEK168I 


XSOBPG-IEKCSR 




1 IEK169I 


XIOOP-IEKCIO 





r 


J. y ^ 

Routine in Which] Phase in Which) 


) Message 

j Number 
1 


Message Number 
Is Generated 


) Message Number) 

) Is Generated ) 
_4. j 


) IEK170I 


. 

XIOOP-IEKCIO 


T 1 


) IEK171I 


XSUBPG-IEKCSR 




) IEK176I 


XDO-IEKCDO 




) IEK192I 


XGO-IEKCGO, 
XCLASS-IEKDCL 




] IEK193I 


XCLASS-IEKDCL 




j IEKl9m 


XDATYP-IEKCDT 




j IEK197I 


XIOPST-IEKDIO 




] IEK199I 


XSUBPG-IEKCSR 




] IEK200I 


XARITH-IEKCAR 




) IEK202I 


XDATYP-IEKCDT, 
XSPECS-IEKCSP 




) IEK204I 


XIOPST-IEKDIO 




) IEK205I 


XGO-IEKCGO 




1 IEK206I 


XARITH-IEKCAR 


) PHASE 10 ) 


) IEK207I 


DSPTCH-IEKCDP 




) IEK208I 


DSPTCH-IEKCDP 




j IEK209I 


XDATYP-IEKCDT 




1 IEK211I 


CSORN-IEKCCR 




) IEK212I 


XIOPST-IEKDIO 




j IEK224I 


XCLASS-IEKDCL, 
DSPTCH-IEKCDP 




] IEK225I 


DSPTCH-IEKCDP 




) IEK226I 


CSORN-IEKCCR 




) IEK229I 

I 


XARITH-IEKCAR 


L 4 


) IEK302I 


STALL-IEKGST 


— (■ "1 


) IEK303I 


STALL-IEKGST 


) PHASE 10 ] 


) IEK30m 


STALL-IEKGST 


I (STALL-IEKGST) ) 
j and j 


1 IEK306I 


STALL-IEKGST 


j PHASE 15 j 
) (CORAL) ] 


1 IEK307I 


CORAL- lEKGCR 




) IEK308I 


STALL-IEKGST 




) IEK310I 


STALL-IEKGST 
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i 


Routine in Which 


Phase in Which j 


1 Message 

1 Number 
i______ 


Message Number 
Is Generated 


Message Number | 

Is Generated | 

. J 


1 IEK312I 


^ 

STALL-IEKGST 


PHASE 10 1 
(STALL-IEKGST) | 


1 IEK31tH 


STALL-IEKGST 


and 1 
PHASE 15 1 


1 IEK315I 


STALL-IEKGST 


(CORAL) 1 


1 IEK317I 


STALL-IEKGST 




1 IEK318I 


NDATA-IEKGDA 




1 IEK319I 


NDATA-IEKGDA 




1 IEK320I 


NDATA-IEKGDA 




1 IEK322I 


STALL-IEKGST 




1 IEK323I 


STALL-IEKGST 




1 IEK332I 


STALL-IEKGST 




1 IEK334I 


STALL-IEKGST 




1 IEK350I 


NDATA-IEKGDA 




1 IEK352I 


NDATA-IEKGDA 




1 IEK353I 


CORAL- lEKGCR 




1 IEK355I 


CMSIZE-IEKGCZ 




1 IEK356I 
L . 


STALL-IEKGST 


. J 


1 IEK500I 


, 

BLTNFN-IEKJBF 
DFUNCT-IEKJDF 


^ 


j IEK501I 


DFUNCT-IEKJDF, 

UNARY-IEKKUN 

(EXPON) 




1 IEK502I 


UNARY-IEKKUN 


PHASE 15 1 




(EXPON) 


(PHAZ15) 1 


1 IEK503I 


ALTRAN-IEKJAL 




1 IEK50UI 


UNARY-IEKKUN 




1 IEK505I 


PHAZ15-IEKJA 




1 IEK506I 


ALTRAN-IEKJAL 




I IEK507I 


BLTNFN-IEKJBF 




1 IEK508I 


BLTNFN-IEKJBF 




1 IEK509I 


PHAZ15-IEKJA 




1 IEK510I 


ANDOR-IEKJAN 




1 IEK512I 


FINISH-IEKJFI 





r 1 


r T n 

Routine in Which | Phase in Which | 


1 Message 
1 Number 


Message Number 
Is Generated 


1 Me s s ag e Number | 
1 Is Generated j 


^ ^ 

1 IEK515I 

1 


RELOPS-IEKKRE 


_+ 4 


1 IEK516I 

1 
I 


FINISH-IEKJFI 


1 PHASE 15 1 


1 IEK520I 


ALTRAN-IEKJAL 


1 (PHAZ15) 1 


1 IEK521I 


ALTRAN-IEKJAL 




1 IEK522I 


ALTRAN-IEKJAL 




1 IEK523I 


ALTRAN-IEKJAL 




1 IEK52UI 


ALTRAN-IEKJAL 




1 IEK525I 


ALTRAN-IEKJAL 
RELOPS-IEKKRE 




1 IEK529I 


DFUNCT-IEKJDF 
(lEKKPR) 




1 IEK530I 


SUBADD-IEKKSA 




j IEK531I 


ALTRAN-IEKJAL 




1 IEK5U1I 


DFUNCT-IEKJDF 




1 IEK5U2I 


ALTRAN-IEKJAL 




1 IEK550I 


ALTRAN-IEKJAL, 

DFUNCT-IEKJDF 

(lEKKPR) 




1 IEK552I 


DFUNCT-IEKJDF 




1 IEK570I 


GENER-IEKLGN, 

TXTLAB-IEKLAB, 

TXTREG-IEKLRG 




1 IEK580I 


ALTRAN-IEKJAL, 

SUBMLT-IEKKSM, 

PHAZ15-IEKJA, 

MATE-IEKLMA, 

FINISH-IEKJFI 




L 




_4. J 


1 IEK600I 


TOPO-IEKPO 


— J. ^ 


1 IEK610I 


TOPO-IEKPO 




1 IEK620I 


TOPO-IEKPO 




1 IEK630I 


TOPO-IEKPO 




1 IEK640I 


GETDIK-IEKPGK 


1 PHASE 20 1 


1 IEK650I 


GETDIK-IEKPGK 




1 IEK660I 


RELCOR-IEKRFL 




1 IEK670I 


BAKT-IEKPB 
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^ ^ 

Phase in Which 
Message Number 
Is Generated 



Message 
Number 



Routine in Which 
Message Number 
Is Generated 



IEK671I 



BIZX-IEKPZ 



PHASE 20 



IEK710I 
IEK720I 
IEK730I 
IEK7U0I 
IEK750I 
IEK760I 
IEK770I 



lEKTFM 
lEKTFM 
lEKTFM 
lEKTFM 
lEKTFM 
lEKTFM 
lEKTFM 



PHASE 10 



■H 



IEK800I 



MAINGN-IEKTA, 
TSTSET-IEKVTS 



PHASE 25 



IEK999I 
lEKOOlI 



IEKP30 
IEKP30 



PHASE 30 
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APPENDIX I: THE TRACE AND DUMP FACILITIES 



Included in the FORTRAN IV (H) compiler 
are two optional facilities which provide 
output that can be used to analyze compiler 
operation and to diagnose compiler malfunc- 
tion. These two facilities are TRACE and 
DUMP. 



TRACE 



The TRACE facility can be used to trace 
the creation of and the modifications made 
to the information table and intermediate 
text, and to provide various other types of 
diagnostic information. This facility is 
activated by the inclusion of the TRACE 
keyword parameter in the PT^M field of the 
EXEC statement used to invoke the compiler. 
The format of this parameter is: 



TRACE=value 

where : 

value may be either; (1) any one of 
the basic keyword values that appear 
in Table 55, or (2) any value that is 
formed by adding two or more of these 
basic keyword values. 



The type of diagnostic information to be 
provided by the compiler for a given compi- 
lation or batch of compilations is deter- 
mined according to the value specified for 
the TRACE keyword. Table 55 defines the 
type of diagnostic information produced for 
each of the basic keyword values for the 
TRACE keyword. If one of these values is 
specified, the corresponding information is 
provided by the compiler. For example, if 
the basic keyword value of 4 is specified, 
the compiler generates PHAZ15 diagnostic 
information. 



If the value given to the TRACE keyword 
is the sum of two or more basic keyword 
values, then the compiler will produce the 
type of information that corresponds to 
each basic keyword value that was added to 
form that value. For example, if the value 
20 (the sum of basic keyword values 4 and 
16) is specified, the compiler will gener- 
ate both PHAZ15 diagnostic information and 
Phase 20 diagnostic information. 



•Table 55. Basic TRACE Keyword Values and 
Output Produced 



r T 

Basic 

Keyword 

Values 



16 
6U 



128 



256 



512 



H- 



1024 



2048 



4096 



Output Produced 



Phase 10 diagnostic information 



PHAZ15 diagnostic information 



Phase 20 diagnostic information 



Printout of: 

1. Information table and inter- 
mediate text as they appear 
before the execution of 
STALL in Phase 10. 

2. Information table as it 
appears after the execution 
of STALL in Phase 10. 

3. Intermediate text as it 
appears after the execution 
of PHAZ15 in Phase 15. 

4. Information table as it 
appears after the execution 
of CORAL in Phase 15. 

5. Information table and inter- 
mediate text as it appears 
after the execution of Phase 
20. 



Block size information for each 
text block (Phase 20) 



Diagnostic information from the 
register assignment routines 
(Phase 20) 



Diagnostic information from the 
text optimization routines (Phase 
20) 



Busy-on-exit information for each 
text block (Phase 20) 



Additional diagnostic information 
from the register assignment rou- 
tines (Phase 20) 



Printout of intermediate text and 
information table before and 
after the execution of Phase 20 
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DUMP 



The dump facility, if activated, will 
cause abnormal termination of compiler 
processing if a program interrupt occurs 
during compilation. It will also cause the 
main storage areas occupied by the com- 
piler, as well as any associated data and 
system control blocks to be recorded on an 
external storage device. The dtamp facility 
is activated by including in the compile 
step of the job: (1) the word DUMP as a 



parameter in the PARM field of the EXEC 
statement, and (2) a SYSABEND data defini- 
tion (DD) statement. 

gote: If the DUMP parameter is specified 
but the SYSABEND DD statement is omitted, 
abnormal termination, accompanied by an 
indicative diamp, will occur if a program 
interrupt is encountered. If a program 
interrupt occurs and the DUMP parameter is 
not specified, the current compilation will 
be deleted and the next compilation will be 
attempted. 
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APPENDIX J: FACILITIES USED BY THE COMPILER 



The following statement, built-in functions and bit-setting facili- 
ties are used by the compiler to produce more efficient object code and 
more efficient use of storage when compiling the compiler. To invoke 
those routines within the compiler which implement the facilities 
requires the inclusion of an additional option to the compiler. The 
option as specified below, is coded: 

PARM. procstep= ( . . . , XL, . . . ) 

(Note: The XL subparameter is not positional.) 

Failure to pass the XL option to the compiler will result in its failure 
to process these features as documented below. The STRUCTURE statement 
will be unrecognized and the remaining extensions will be considered as 
external functions. 



STRUCTURE STATEMENT 



r T 

J GENERAL FORM j 

i. ^ 

STRUCTURE// Vi i,Vi 2, Vi 3, . . . //V21, V22, V23, . . . //Vni» r Vna, Vna, . . . Vnm 
IWHERE: Vi^., Vi2# V^a, . . . V2i,. V221 V23, . . . Vnm 

represent names of variables that will be equated to displace- 
ment values. If these variables are declared in a type state- 
ment, this statement must precede the STRUCTURE statement. 

I- „ ^ 

I Note: The // immediately following the word STRUCTURE may be omitted. | 

L . J 



The variables may be implicitly or explicitly declared as any type or 
length. They must not be dimensioned and must not appear in COMMON or 
EQUIVALENCE Statements. A varialbe may appear more than once in 
STRUCTURE statements within a single program or subprogram provided it 
is given the same displacement by each program. 

If D is the name of a structured variable, it must always appear in 
an executable statement with a single subscript, e.g., D(I). An expres- 
sion such as D(I) refers to a variable of the type specified for D which 
is located in main storage at the base address specified by the value of 
the subscript expression, I, plus a displacement equal to the total 
number of bytes in the length specification of all the variables preced- 
ing D in the STRUCTURE statement in which it appears. For the object 
program to execute successfully, it is essential that the value of the 
subscript plus the displacement always be an integral multiple of the 
length of the referenced field. Displacements may not exceed 255. The 
subscript expression must be declared as integer or logical. 

EXAMPLE ; 

LOGICAL* 1 AD J, MT 
INTEGER CH, PTR 
STRUCTURE CH, PTR//ADJ//CH, MT 

Appendix J: Facilities Used By The Compiler 235 



Here the STRUCTURE statement is used to define a two-word structure 
where the high-order byte of each word is overlapped by a one-byte 
field. 



I I 
I 1 



ADJ MT 



CE PTR 



If J contains a pointer to such a structure, its fields may be 
referenced as ADJ(J), CH(J), MT(J), and PTR(J). 

If a structured variable is used incorrectly the compiler may issue a 
diagnostic message. A complete list of the FORTRAN IV (H) compiler mes- 
sages appears in the publication IBM System/360 Operating System Mes- 
sages and Codes , Form C28~6631. 



BUILT-IN FUNCTIONS 



LAND 



I GENERAL FORM j 

I _ ^ 

•.=• ..LAND (a, b) ••• 

i WHERE: a, b may be any 1-byte or 4-byte logical or integer 
expression. 

L . J 

The value of LAND is obtained by adding the individual bits of the 
arguments. The resulting value will be considered to be Logical* U but 
may be used as an integer. 



LOR 



(general FORM | 

I ^ 

...=.. .LOR(a, b)... 

I WHERE: a, b may be any 1-byte or 4-byte logical or integer 
expression. 

I . . J 

The value of LOR is obtained by oring the individual bits of the 
arguments. The resulting value will be considered to be Logical*4 but 
may be used as an integer. 
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LXOR 



I GENERAL FORM | 

|. ^ 

..=.,.LXOR(a, b)«.. 

I WHERE; a, b may be any 1-byte or 4-byte logical or integer 
expression. 

L J 



The value of LXOR is obtained by exclusive oring the individual bits 
of the arguments. The resulting value will be considered to be 
Logical +4 but may be used as an integer. 



LCOMPL 



r— — ■ 1 

j GENERAL FORM | 

I ^ _ ^ 

I I 

j...=..,LCOMPL(a) j 

I I 

I WHERE I a may be any 1-byte or 4-byte logical or integer expression. | 

L . J 



The value of LCOMPL is obtained by complementing the individual bits 
of the argument. The resulting value will be considered to be Logical*4 
but may be used as an integer. 



SHFTL and SHFTR 



I ■ — • 1 

I GENERAL FORM j 

I- . — „__ ^ 

• • • — . • . SHFTL \<J.K).../ ... — ... SHFTR (J^K) . . . 

I WHERE: J is a U-byte variable. 

K is the actual number of bits to be shifted. 

^ , J 



The values of SHFTL and SHFTR are obtained by shifting the first 
argument left or right the number of bits specified by K. The resulting 
value will be considered to be Logical* 4 but may be used as an integer. 
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TBIT 



r ■ 1 

I GENERAL FORM j 

J. . _ ^ 

|...TBIT(A,K)... I 

I I 

(WHERE: A is any variable 4-bytes or less in length | 

I K is the number assigned to the bit to be tested. j 

L . J 



The value of TBIT is .TRUE. or .FALSE. depending on whether bit 
position K of the variable A is on or off. Bit is the leftmost bit of 
variable A. The resulting value will be declared as Logical*4. 



MOD24 



r ' ■" 1 

I GENERAL FORM | 

|. -^ ^ 

|...=...M0D2t»(A) I 

I I 

I WHERE: A must be a U-byte integer variable. | 

L . J 



The value of MOD24 is the same as its argument except that the high- 
order byte is set to zero. The resulting value will be declared 
Integer* 4. 



BIT- SETTING FACILITIES 



BITON 



J. . . ^ 

I GENERAL FORM | 

|. _ ^ 

|V = BITON (V,K) I 

I I 

I WHERE: V must be a single variable; it may be subscripted. ) 

I K is the number assigned to the bit to be set. j 

L ^ J 



This facility sets the bit at position K in the variable V "on". Bit 
is the leftmost bit of variable V. 
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BITOFF 



r — ' 1 

I GENERAL FORM | 

|.__^ ^ 

|V=BITOFF(V,K) I 

1 I 

I WHERE: V must be a single variable; it may be subscripted. | 

I K is the n\amber assigned to the bit to be set. | 

L ; .^ J 



This facility sets the bit at position K in the variable V "off. 
Bit is the leftmost bit of variable V. 



BITFLP 



r 1 

I GENERAL FORM j 

Y— ^ 

|V=BITFLP(V, K) I 

I I 

I WHERE: V must be a single variable; it may be subscripted. | 

I K is the number assigned to the bit to be set. j 



This facility sets the bit at position K in the variable V to its 
inverse. Bit is the l€>ftmost bit of variable V. 

In all of the bit-setting facilities K is restricted to integer 
values from to 63 (0<K^63). If V is subscripted, the value of the 
subscript must be the same in both uses, to insure that only a single 
variable is referenced. 
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APPENDIX K: MICROFICHE DIRECTORY 



The microfiche directory (Table 56) is designed to help find named areas of code in 
the program listing, which is contained on microfiche cards at installation. Microfiche 
cards are filed in alphameric order by object module name. If a control section, entry 
point, or table is to be located on microfiche, find the name in coliimn one and note the 
associated object module name. You can then find the item on microfiche, via the object 
module name; for example, object module lEKOBJTl is on card IEKOBJTl-1. 



The other columns provide a description of the item, its phase, its overlay segment, 
its flowchart ID (where applicable) , and its subroutine directory table number. 



• Table 56. Microfiche Directory (Part 1 of 8) 

^ ^ . ^. 





1 Description 

L 


[object 
1 Module 
JName and 

CSECT, 

Name 


1 Phase 


[Overlay 
Segment 


1 Chart 
|ID 

L 


1 Sub- 1 
[routine J 
Directory] 
[Table 1 
j Number | 


Symbolic Name 


r 

1* - Only 
[Mentioned 
in Chart 


r 
ADMDGN-IEKVAD 


r 

Code generation routine 


IEKVAD# 


125 


. 

13 


[. — ^ 


— 


[Table 14 | 


AFIXPI 


Entry point 


lEKAFP 


FSD 


1 




— 


[Table 6 | 


AFIXPI-IEKAFP 


Exponentiation Routine 


lEKAFP 


FSD 


1 




— 


[Table 6 | 


ALTRAN-IEKJAL 


Arithmetic translation 
routine 


IEKJAL# 


15 


5 




07 


Table 9 | 


ANDOR-IEKJAN 


Text generation routine for 
logical operators 


IEKJAN# 


15 


5 




07* 


Table 9 | 


BACMOV-IEKQBM 


Text optimization routine 


IEKQBM# 


20 


9 




12 


Table 12 | 


B/iKT-IEKPB 


Structural determination 
routine 


IEKPB# 


20 


8 




10* 


Table 12 | 


BITNFP-IEKVFP 


Code generation routine 


IEKVFP# 


25 


13 




— 


Table 14 | 


BIZX-IEKPZ 


MVX routine 


lEKPZtt 


20 


8 




10* 


Table 12 | 


BKDMP-IEKRBK 


TRACE routine for full 
register assignment 


IEKRBK# 


20 


10 




— 


Table 12 | 


BKPAS-IEKRBP 


Local register assignment 
routine 


IEKRBP# 


20 


10 




16 


Table 12 | 


BLS-IEKSBS 


Branching optimization 
routine 


IEKSBS# 


20 


10 




10* 


Table 12 | 


BLTNFN-IEKJBF 


In-line function routine 


IEKJBF# 


15 


5 




07* 


Table 9 | 


BRLGL-IEKVBL j 


Code generation routine 1 


IEKVBL# 


25 


13 




— 


Table 14 | 


CGEN-IEKWCN 


Array initialization area 


lEKWCN 


25 1 


13 




— 


Table 14 1 


CIRCLE- lEKQCL 


Utility subroutine | 


IEKQCL# 1 


20 1 


9 i 




— 


Table 13 | 


CLASIF-IEKQCF | 


Utility subroutine | 


IEKQCF# 1 


20 1 


9 




1 


Table 13 1 
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• Table 56. Microfiche Directory (Part 2 of 8) 

r T T T T T T 1 





Description 

1 , 


1 

Object 

Module 

Name and 

CSECT 

Name 
, 


Phase 




Overlay 
Segment 




Chart 
ID 


Sub- 

routir 

Direct 

Table 

N\imbei 




1P> 


Symbolic Name 




♦ - Only 
Mentioned 
in Chart 




:ory 


CMAJ0R-IEKJA2 


Y , 

Backward connection table 


IEKJA2 


15/20 


4 




Table 


10 


CMSIZE-IEKGCZ 


Base and displacement routine 


IEKGCZ# 


15 


6 


09* 


Table 


9 


CNSTCV-IEKKCN 


Constant conversion routine 


IEKKCN# 


15 


5 


— 


Table 


9 


CORAL- lEKGCR 


Control routine for CORAL 
segment of phase 15. 


IEKGCR# 


15 


6 


09 


Table 


9 


CPLTST-IEKJCP 


Arithmetic triplet routine 


lEKJCPft 


15 


5 


07* 


Table 


9 


CSORN-IEKCCR 


Collection, conversion, and 
entry placement routine 


IEKCCR# 


10 


2 


— 


Table 


8 


CXIMAG-IEKRCI 


Local register assignment 


IEKRCI# 


20 


10 


— 


Table 


12 


DATOUT-IEKTDT 


DATA statement processing 
routine 


IEKTDT# 


15 


6 


09* 


Table 


9 


DCLIST-IEKTDC 


Listing routine 


IEKTDC# 


FSD 


1 


— 


Table 


6 


DELTEX-IEKQDT 


Entry point 


IEKQMT# 


20 


9 


— 


Table 


13 


DFILE-IEKTDF 


DEFINE FILE statement routine 


IEKTDF# 


15 


6 


09* 


Table 


9 


DFUNCT-IEKJDF 


In-line, external subprogram, 
and library function routine 


IEKJDF# 


15 


5 


07* 


Table 


9 


DSPTCH-IEKCDP 


Dispatcher, key word, and 
utility routine 


lEKCDPtt 


10 


2 


03 


Table 


8 


DUMP15-IEKLER 


Error recording routine 


IEKLER# 


15 


5 


— 


Table 


9 


ENDFILE 


Entry point 


lEKAAOO 


FSD 


1 


01 


Table 


6 


END-IEKUEN 


Object module completion 
routine 


lEKUENtt 


25 


13 


21 


Table 


14 


ENTRY- lEKTEN 


Epilogue and prologue 
generating routine 


IEKTEN# 


25 


13 


21* 


Table 


14 


EPILOG- lEKTEP 


Subprogram epilogue generat- 
ing routine 


lEKTEPtt 


25 


13 


21* 


Table 


14 


EQVAR-IEKGEV 


COMMON and EQUIVALENCE 
processing routine 


IEKGEV# 


15 


6 


09* 


Table 


9 


ESD 


Entry point 


lEKTLOAD 


FSD 


1 


— 


Table 


6 


FAZ25-IEKP25 


COMMON data area 


IEKP25 


25 


13 


— 


Table 


14 


FCLT50-IEKRFL 


Text checking routine 


IEKRFL# 


20 


10 


— 


Table 


12 


FILTEX-IEKPFT 


Entry point 


IEKPGK# 


20 


7 


— 


Table 


13 
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• Table 56. Microfiche Directory (Part 3 of 8) 



1 

1 Symbolic Name 

L 


r 1 

Description 


. — ^ 

Object 
Module 
Name and| 
CSECT 1 
Name | 
J 




Phase 


r ■ — T 1 

1 Chart 

|ID 

j . . 

1* - Only 
Overlay | Mentioned 
Segment] in Chart 

L . 


1 

Sub- 1 
routine | 
Directory I 
Table 1 
Number j 
J 


Y 

1 FINISH- lEKJFI 




Statement completion routine 


IEKJFI# 


15 


r T 1 
5 1 07* 


Table 


1 
9 1 


IFIOCS, FlOCStt 


Entry points 


lEKFIOCS 


FSD 


1 1 


Table 


6 1 


IFIXPI, FIXPI# 


Entry points 


lEKAFP 


FSD 


1 1 


Table 


6 1 


IFNCALL-IEKVEN 


Calling sequence generating 
routine 


IEKVFN# 1 


25 


13 1 20* 


Table 


14 1 


1 FOLLOW- lEKQF 


Entry point 


IEKQCL# 1 


20 


9 1 


Table 


13 1 


I FORMAT- lEKTFM 


Generates format text for 
object module 


IEKTFM# i 


10 


2 1 


Table 


8 1 


IFREE-IEKRFR 


Local register assignment 
routine 


IEKRFR# 


20 


10 1 


Table 


12 1 


1 FUNRDY-IEKJFU 


Implicit library function 
reference routine 


IEKJFU# 


15 


5 1 


Table 


9 1 


IFWDPAS-IEKRFP 


Table building routine 


lEKRFRtt 


20 


10 1 15 


Table 


12 1 


IFWDPSl-IEKRFl 


Local register assignment 
routine 


IEKRF1# 


20 


10 1 15* 


Table 


12 1 


IGENER-IEKLGN I 


Text output routine 


IEKLGN# 


15 


5 1 08 


Table 


9 1 


IGENRTN-IEKJGR | 


Text entry routine 


lEKJGRtt 


15 


5 1 07* 


Table 


9 1 


IGETCD-IEKCGC 


Preparatory subroutine 


lEKCGC 


10 


2 1 03* 


Table 


8 1 


IGETDIC-IEKPGC 


Entry point 


IEKPGK# 


20 


7 1 


Table 


13 1 


IGETDIK-IEKPGK | 


Utility subroutine 


IEKPGK# 


20 


7 1 


Table 


13 1 


IGETWD-IEKCGW | 


Utility subroutine 


lEKCGW 


10 


2 1 


Table 


8 1 


IGLOBAS-IEKRGB 


Global register assignment 
routine 


IEKRGB# 


20 


10 1 17 


Table 


12 1 


jGOTOKK-IEKWKK 


Branching routine 


IEKWKK# 


25 


13 1 


Table 


14 1 


1 IBCOM, IBCOM# 


Entry points 


lEKFCOMH 


FSD 


1 1 


Table 


6 1 


IIEKAAOO 


Compiler initialization 
routine 


lEKAAOO 


FSD 


1 1 01 


Table 


6 1 


1 lEKAAOl 


Default options, 6DDNAMES for 
compiler 


lEKAAOl 


FSD 


1 1 


Table 


6 1 


j IEKAA9 


Entry point 


lEKAAOO 


FSD 


1 1 01* 


Table 


6 1 


1 lEKAGC 


Entry point 


lEKAAOO 


FSD 


1 1 02* 


Table 


6 1 


1 lEKAREAD 


Entry point 


lEKCGC 


10 


2 1 


Table 


8 1 


IIEKARW 

L i 


Utility subroutine 

1 J 


lEKARW 

1 J 


20 
J 


7 1 


Table 


13 1 
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r 1 


P ^ 


1 


r 1 


r T 1 

1 Chart 









Object 
Module 
Name and 
CSECT 




|ID 
1 


J 


Sub- 
routine 
Directory 
Table 








1 — 

1* - Only 
Overlay | Mentioned 


1 Symbolic Name 
1 lEKATB 


Description 
_ „ 

Diagnostic trace routine 


Name 

[ ^ 

IEKATB# 


Phase 

^ ^ 

FSD 


Segment | in 
1 1 


Chart 




Number 
h 

Table 6 


1 lEKATM 


Timing routine 


lEKATM 


FSD 


1 1 


— 


Table 6 


1 lEKCIN 


Entry point 


lEKCDPtt 


10 


2 1 


03* 


Table 8 


1 lEKCLC 


Entry point 


IEKCCR# 


10 


2 1 


— 


Table 8 


IIEKCSI, 


Entry points 


IEKCCR# 


10 


2 1 


— 


Table 8 


IIEKCS2, IEKCS3 














i lEKFCOMH 


Formatted compile- time I/O 
routine 


lEKFCOMH 


FSD 


1 1 




Table 6 


1 lEKFIOCS 


Interface between compiler, 
lEKFCOMH and QSAM 


lEKFIOCS 


FSD 


1 1 


— 


Table 6 


1 lEKGAl 


COMMON data area for CORAL 


lEKGAl 


15 


6 1 


— 


Table 10 


] lEKGMP 


Storage map routine 


lEKGMP 


25 


13 1 


20* 


Table 14 


1 lEKIORTN 


Entry point 


lEKAAOO 


FSD 


1 1 


— 


Table 6 


J IEKJA2 


Backward connection table 


IEKJA2 


15/20 


t» 1 


— 


[Table 10 


] IEKJA3 


Function information tables 


IEKJA3 


15 


5 1 


— 


Table 1 


1 lEKJAU 


Forward connection table 


IEKJA4 


15/20 


'* 1 


— 


Table 10 


1 lEKJEX 


Entry point 


IEKKUN# 


15 


5 1 


07* 




1 lEKJMO 


Entry point 


IEKJCP# 


15 


5 1 


07* 




1 lEKKNG 


Entry point 


IEKKOP# 


15 


5 1 


— 




1 lEKKNO 


Entry point 


IEKJAN# 


15 


5 1 


07* 




1 lEKKOS 


Coordinate assignment routine 


lEKKOS 


10 


2 1 


04* 


Table 8 


1 lEKKPR 


Entry point 


IEKJDF# 


15 


5 1 


07* 




1 lEKKSW 


Entry point 


IEKKUN# • 


15 


5 1 


— 




1 lEKLTB 


Function table 


lEKLTB 


15 


5 1 


— 


Table 10 


( lEKPOV 


Entry point 


IEKPGK# 


20 


7 1 


— 


Table 13 


1 IEKP30 


Controlling routine 


IEKP30 


30 


12 1 


22 


Table 15 


1 lEKQAB 


Entry point 


lEKQAAtt 


20 


8 1 


— 


Table 13 
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• Table 56. Microfiche Directory (Part 5 of 8) 



I— -■ 



T, 

1 


r 

Description 


r 1 

1 

Object 

Module 

Name and 

CSECT 

Name 
J 


r 1 

1 

Phase 

L J 


Overlap) 
Segment 


1 Chart 

JID 

1 




Sub- 
routir 
Direct 
Table 
Numbei 
^ 


'^^ 1 


Symbolic Name | 


1 ^ 

1* - Only 
'1 Mentioned 
|in Chart 
± . J 


,ory 1 


-1 

lEKTLOAD 


— ___—.———— — ___— — . 

ESD, TXT, RLD, and loader END 


lEKTLOAD 
lEKTLOAD 1 


1 

FSD 


r» 


T 


09* 


Table 


6 1 


lEKTXT 


Entry point 


FSD 


1 




— 


Table 


6 1 


lEKUND 


Entry point 


lEKTLOAD 


FSD 1 


1 




— 


Table 


6 1 


lEKURL 


Entry point 


lEKTLOAD 


FSD 


1 




— 


Table 


6 1 


lEKUSD 


Entry point 


lEKTLOAD j 


FSD 


1 




— 


Table 


6 1 


lEKXRS 1 


Utility routine for XREF 


lEKXRS 


10 


2 




— 


Table 


8 1 


lEND 


Entry point 


lEKTLOAD 1 


FSD 


1 




— 


Table 


6 1 


INVERT- lEKP IV 




IEKPGK# 


20 


7 




— 


Table 


13 1 


lOSUB-IEKTIS 


Calling sequence generating 
routine 


IEKTIS# 1 


25 1 


13 




20* 


Table 


in 1 


I0SUB2-IEKTI0 


Calling sequence generating 
routine 


IEKTIO# 


25 


13 




— 


Table 


m 1 


KORAN- lEKQKO 


Utility subroutine 


IEKQKO# ! 


20 


9 




12* 


Table 


13 1 


LABEL-IEKTLB 


Statement number routine 


IEKTLB# 


25 1 


13 




20* 


Table 


m 1 


LABTLU-IEKCLT 


Statement number utility 
routine 


IEKCLT# 1 


10 


2 




— 


Table 


3 1 


LISTER-IEKTLS 


Listing routine 


IEKTLS# 


25 


13 




— 


Table 


14 1 


LOC-IEKRLl 


Register assignment data area 


lEKRLl 


20 


10 




— 


Table 


12 1 


LOOKER- lEKLOK 


Subprogram table look up 
routine 


lEKLOK 


15 


5 




07* 


Table 


9 1 


LORAN-IEKQLO 


Entry point 


IEKQKO# 


20 1 


9 




12* 


Table 


13 1 


LPSEL-IEKPLS 


Control routine 


IEKPLS# 


20 


7 




10 


Table 


12 1 


MAINGN-IEKTA 


Control routine 


IEKTA# 


25 


13 




20 


Table 


14 1 


MAINGN2-IEKVM2 


Control routine 


IEKVM2# 1 


25 


13 




— 


Table 


14 1 


MATE-IEKLMA 


MVS, MVF, and MVX routine 


IEKLMA# : 


15 1 


5 




— 


Table 


9 1 


MODFIX-IEKQMF 


Entry point 


IEKQCF# 


20 


9 




— 


Table 


13 1 


MOVTEX-IEKQMT 


Utility subroutine 


lEKQMTtt 


20 


9 




— 


Table 


13 1 
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r 1 

1 


P_ , 1 

Description 


. 

Object 
Module 
Name and 
CSECT 
Name 



r 1 

Phase 




r T 1 

1 Chart 

|ID 

1 . 




Sub- 


1 Symbolic Name 
1 _ 


1* - Only 
Overlay j Mentioned 
Segment | in Chart 


1. V./U i-^ 11^ 

Directory 
Table 
Number 



r i 

IMSGWRT-IEKP31 


. 

Error message writing routine 




IEKP31# 


1 
30 


12 1 


22* 


Table 15 


INDATA-IEKGDA 


Data text routine 


IEKGDA# 


15 


6 1 


09* 


Table 9 


lOPlCHK-IEKKOP 


Operand one routine 


IEKKOP# 


15 


5 1 


— 


Table 9 


INLIST-IEKTNL 
1 


NAMELIST statement routine 


IEKTNL# 


15 


6 1 


09* 


Table 9 


1 

1 PACKER- lEKTPK 


TXT record packing routine 


IEKTPK# 


25 


13 1 


— 


Table 14 


J PAGEHEAD 


Entry point 


lEKAAOl 


FSD 


1 1 


— 


Table 6 


IPAREN-IEKKPA 
1 


Parenthesis routine 


IEKKPA# 


15 


5 1 


07* 


Table 9 


1 
IPARFIX-IEKQPX 


Entry point 


IEKQCF# 


20 


9 1 


— 


Table 13 


IPERFOR-IEKQPF 


Constant routine 


IEKQPF# 


20 


9 1 


— 


Table 13 


1 PHASE 


Entry point 


lEKATM 


FSD 


1 1 


— 


Table 6 


1 PHASS 


Entry point 


lEKATM 


FSD 


1 1 


— 


Table 6 


1 PHAZSS 


Entry point 


lEKATM 


FSD 


1 1 


— 


Table 6 


IPHAZ15-IEKJA 


Control routine for PHAZ15 
segment of phase 15 


IEKJA# 


15 


5 1 


06 


Table 9 


JPHIO-IEKCAA 


COMMON data area 


lEKCAA 


10 


2 1 


— 


Table 8 


1PH15-IEKJA1 


COMMON data area 


lEKJAl 


15 


5 1 


— 


Table 1 


1 PLSGEN-IEKVPL 


Code generation routine 


IEKVPL# 


25 


13 1 


— 


Table 14 


1 PROLOG- lEKTPR 


Subprogram prologue generat- 
ing routine 


IEKTPR# 


25 


13 1 


21* 


Table 14 


1 PUTOUT 


Entry point 


lEKAPT 


FSD 


1 1 


— 


Table 6 


IPUTOUT-IEKAPT 


Service routine 


lEKAPT 


FSD 


1 1 


— 


Table 6 


IPUTX-IEKCPX 


Entry placement utility 
routine 


IEKCPX# 


10 


2 1 


— 


Table 8 


1 REDUCE- lEKQSR 


Strength reduction routine 


IEKQSR# 


20 


9 1 


13 


Table 12 


1 

IREGAS-IEKRRG 


Full register assignment 
routine 


IEKRRG# 


20 


10 1 


m 


Table 12 


IRELCOR-IEKRRL 


Entry point 


lEKRFLtt 


20 


10 1 


19* 


Table 12 


IRELOPS-IEKKRE 

1 


Relational operator routine 


IEKKRE# 


15 


5 1 


07* 


Table 9 


1 RETURN- lEKTRN 


RETURN statement routine 


IEKTRN# 


25 


13 1 


20* 


Table 14 


IRLD 


Entry point 


lEKTLOAD 


FSD 


1 1 


— 


Table 6 
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j._„. 





r 1 

Description 

: 


r 

Object 

Module 

Name and 

CSECT 

Name 




1 

Phase 




~1 

Overlay 
Segment 




r ■ 1 

Chart 
ID 

, J 




Sub- 
rout ir 
Direct 
Table 
INximbej 


^f^ 


Symbolic Name 


♦ - Only 
Mentioned 
in Chart 

. 


:ory 


RMAJ0R-IEKJA4 


. 

Forward connection table 


— 

lEKJAU 


15/20 


1 
4 




Table 


10 


SEARCH- lEKRS 


Register loading routine 


IEKRS# 


20 


10 


17* 


Table 


12 


SPLRA-IEKRSL 


Basic register assignment 
routine 


IEKRSL# 


20 


11 


— 


[Table 


12 


SRPRIZ-IEKQAA 


Structured source program 
listing routine 


IEKQAA# 


20 


8 


— 


Table 


13 


SSTAT-IEKRSS 


Status setting routine 


IEKRSS# 


20 


11 


10* 


[Table 


12 


STALL- lEKGST 


COMMON and EQUIVALENCE state- 
ment processing routine 


IEKGST# 


10 


2 


04 


Table 


8 


STOPPR-IEKTSR 


routine 


lEKTSRtt 


25 


13 


— 


Table 


14 


STTEST-IEKKST 


Replacement statement routine 


IEKKST# 


15 


5 


07* 


Table 


9 


STXTR-IEKRSX 


Text updating routine 


IEKRSX# 


20 


10 


18 


Table 


12 


SUBADD-IEKKSA 


Subscript computation routine 


IEKKSA# 


15 


5 


07* 


Table 


9 


SUBGEN-IEKVSU 


Code generation routine 


lEKVSUtt 


25 


13 


20* 


Table 


14 


SUBMLT-IEKKSM 


Subscript computation routine 


lEKKSMtt 


15 


5 


07* 


Table 


9 


SUBSUM-IEKQSM 


Operand and operand value 
replacement routine 


IEKQSM# 


20 


9 


— 


Table 


13 


TALL-IEKRLL 


Assigns storage for 
temporaries 


IEKRLL# 


20 


11 


— 


Table 


12 


TARGET- lEKPT 


Loop and back target routine 


IEKPT# 


20 


7 


10* 


Table 


12 


TENTXT-IEKVTN 


Statement number processing 
and label map routine 


IEKVTN# 


25 


13 


20* 


Table 


14 


TIMERC 


Entry point 


lEKATM 


FSD 


1 


— 


Table 


6 


TNSFM-IEKRTF 


Entry point 


IEKRFL# 


20 


10 


— 


Table 


12 


TOPO-IEKPO 


Back dominator routine 


IEKPO# 


20 


8 


10* 


Table 


12 


TOUT 


Entry point 


lEKATM 


FSD 


1 


— 


Table 


6 


TSP 


Entry point 


lEKATM 


FSD 


1 


— 


Table 


6 


TST 


Entry point 


lEKATM 


FSD 


1 


— 


Table 


6 


TSTSET-IEKVTS 


Code generation routine 


IEKVTS# 


25 


13 


— 


Table 


14 


TXT 


Entry point 


lEKTLOAD 


FSD 


1 


— 


Table 


6 
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r T ■ T- 





Description 

1 _ _ , 


Object 

Module 

Name and 

CSECT 

Name 




Phase 


Overlay 
Segment 




Chart 

ID 

J 


Sub- 
rout ir 
Direct 
Table 
Number 



\^ 


Symbolic Name 


* - Only 
Mentioned 
in Chart 


,ory 




r 




— — — — 










TXTLAB-IEKLAB 


Statement number processing 


lEKLABtt 


15 


5 


08* 


Table 


9 


TXTREG-IEKLRG 


Standard text processing 
routine 


IEKLRG# 


15 


5 


08* 


Table 


9 


TYPLOC-IEKQTL 


Strength reduction routine 


IEKQTL# 


20 


9 


13* 


Table 


13 


UNARY-IEKKUN 


Arithmetic triplet and 
exponentiation operator 
routine 


IEKKUN# 


15 


5 


07* 


Table 


9 


UNRGEN-IEKVUN 


Code generation routine 


IEKVUN# 


25 


13 


— 


Table 


14 


WRITEX-IEKQWT 


Diagnostic trace printing 
routine 


IEKQWT# 


20 


9 


— 


Table 


13 


XARITH-IEKCAR 


Arithmetic routine 


IEKCAR# 


10 


2 


— 


Table 


8 


XCLASS-IEKDCL 


Text generation utility 
routine 


IEKDCL# 


10 


2 


03* 


Table 


8 


XDATYP-IEKCDT 


DATA and TYPE keyword routine 


IEKCDT# 


10 


2 





Table 


8 


XDO-IEKCDO 


DO keyword routine 


IEKCDO# 


10 


2 


— 


Table 


8 


XGO-IEKCGO 


GO TO keyword routine 


IEKCGO# 


10 


2 


— 


Table 


8 


XIOOP-IEKCIO 


Input/output statement 
routine 


IEKCIO# 


10 


2 


— 


Table 


8 


XIOPST-IEKDIO 


ASSIGN, RETURN, FORMAT, 
PAUSE, BACKSPACE, REWIND, END 
FILE, STOP, and END table 
entry routine 


IEKD10# 


10 


2 




Table 


8 


XPELIM-IEKQXM 


Common expression elimination 
routine 


IEKQXM# 


20 


9 


11 


Table 


12 


XREF-IEKXRF 


XREF routine 


lEKXRF 


10 


3 


— 


Table 


8 


XSCAN-IEKQXS 


Local block scan routine 


IEKQXS# 


20 


9 


— 


Table 


13 


XSPECS-IEKCSP 


COMMON, DIMENSION, and EQUI- 
VALENCE table entry routine 


IEKCSP# 


10 


2 


— 


Table 


8 


XSUBPG-IEKCSR 


CALL, SUBROUTINE, ENTRY, and 
FUNCTION table entry routine 


IEKCSR# 


10 


2 


-»^ 


Table 


8 


XTNDED-IEKCTN 


DEFINE FILE, NAMELIST, IMPLI- 
CIT, andSTRUCTURE table entry 
routine 


lEKCTNft 


10 


2 


"" 


Table 


8 


YSCAN-IEKQYS 


Entry point 


IEKQXS# 


20 


9 


— 


Table 


13 


ZSCAN POINT 


Entry point 


lEKQXStt 


20 


9 


— 


Table 


13 
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INDEX 



ABS 34 

Absolute constant 65 

Activity table, global register 

assignment 54 
Adcon table 42,74,118 

space reservation 41, 46 

starting address of 56 

in XREF processing 28 
ADCON-IEKAAD 8 
Adcon variable 4 5 

Addition, skeleton instructions 170 
Additive text, elimination of 68 
Address 

computation for array elements 221 

constant 13,15,43-44 
reservation of 70 

field of TXT record 70 

relative 41 

assignment of 15 
Adjective codes 143-144 
ADMDGN-IEKVAD 112,240 
AFIXPI-IEKAFP 80,240 
AFIXPI 80,240 
AIMAG 35 
Alter option table routine 204 

tables 205 
ALTRAN-IEKJAL 31, 36„ 90, 93, 240 
Anchor point 36 
AND 34,36 

ANDOR-IEKJAN 36,93,240 
Argument save table 36 
Arithmetic 

expressions 

elimination of 65-66 
reordering 32-33 
special processing 33 

interruptions 187 

operations, basic register assignment 
49-50 

statements, processing 24 

subroutines 23-24 

translation 29,31-32,42 
Array 21 

elements, address computation 222 

relative address for 43 
Arrays 165 

bit strip 72-73 

as parameters 222 
ASSIGN statement 23,31 
Assigned GO TO operator 163 



Back dominators 57,219 

determination of 57,58 

in common expression elimination 65 
Back targets 57,58,225 

determination of 59-60 

pointer to 63 
BACKSPACE processing 194 



BACKSPACE statement 72,178,18 6 
Backward connections 30,39-40 

field 40 

table 41,54 
Backward movement 66-67,106 

example of 173 
BACMOV-IEKQBM 66,67,107,24 
BAKT-IEKPB 57,59,60,107,240 
Balanced tree notation 120 
Base value of equivalence group 44 
Base variables 45 
Basic register assignment 49,226 
Binary 

operators 157 

shift operation 160 
Bit-setting facilities 238 
Bit strip arrays 72 
BITFLP 239 

BITNFP-IEKVFP 112,240 
BITOFF 239 
BITON 238 

BIZX-IEKPZ 61,107,240 
BKDMP-IEKRBK 107,240 
BKPAS-IEKRBP 53,54,107,240 
Blanks, in source statements 21 
BLKEND field 31,150,151 
Block determination for branching 

optimization 56-57 
BLS-IEKSBS 55,69,107,240 
BLTNFN-IEKJBF 34,35,93,240 
Boundary alignment option (IHCADJST) 

177,187 
Branch 

candidate 74 

constant 68 

instruction optimization 55 

operator (B) 157 

operator (other) 160 

optimization 48 
0PT=1 55-56 
0PT=2 6 9 

processing, phase 25 74 

table 133-134 
entry 72 

text entry 65 

true or false skeleton instructions 167 

variable 68 
Branch on index high, low, or equal 15 9 
Branching optimization 47 

block determination for 56-57 

0PT=1 55-56 

0PT=2 69 
BRLGL-IEKVBL 112,24 
Buffering 19 2 

IHCDIOSE 198 
Built-in functions 236 
Busy-on-entry 61 

table 61-62 
Busy-on-exit 

criteria 61 

data 225 

full register assignment 0PT=2 68-69 
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table 61-62 
vector field 151 

EVA table 139 

Byte A usage field 

for statement numbers 
for variables 124 

Byte E usage table field 
for statement numbers 
for variables 124 



127,128 



127,128 



Call 23,24,31 

in global register assignment 55 

in local register assignment 54 

phase 25 processing of 72 
Call arguments 162 
Call-by-name 

parameters 75 

variables 46 
Calling sequence 72 
Cataloged procedures 13 
CGEN-IEKWCN 112,240 
CIRCLE-IEKQCL 109,240 
CLASIF-IEKQCF 109,240 
Classification 

code 22 

tables 115-117 
CMAJOR 40,57,59,61,62,225 
CM A JOR- lEKJAZ 95,241 
CMSIZE-IEKGCZ 93,241 
CNSTCV-IEKKCN 93,241 
Code generation, pnase 25 72-74 
Collection subroutines 25 
Common 14,21,23,75 

areas table 95 

block 

name 23 
size 27 

displacement field 124 

entries 25, 27 

expression elimination 65-66,106 
example of 172 

table 131 
Com.munication table 16,17,80 

contents of 16,115-116 
Commutative operations 3 4 
Compiler 

initialization 16-17 

I/O flow 13-15 

generated branch 37 

organization of 13 

purpose of 13 

structure of 15 

termination 20 
Complex 

expressions 33 

variables 27 
Computed GO TO 

operators 159 

skeleton instructions 169 
CONJG 35 
Constant 

complex 27 

dictionary entry 127 

relative addresses for 43 
Constant/variable usage information 36-37 

phase 15 29 



Constructing text information 69-70 
Control flow, phase 20 48 
Conversion 

code 181 

routines 188 

subroutines 25 
Coordinates 27 

assignment of 25,27 
CORAL 18,41-47,225 
CORAL-IEKGCR 41,43,44,46,93,241 
CPLTST-IEKJCP 93,241 
Cross reference 14 
CSORN-IEKCCR 85,241 

in XREF 2 9 
CTLBLK format 193 
Current base address, in register 

assignment 49 
CXIMAG-IEKRCI 107,241 
C1520-IEKJA2 39 



Data definition statements 13 
DATA statement 15,21,26,142 
Data text 

phase 10 21 
format 146 

phase 15 format 150 

rechaining 41,45 

translation 42 
DATOUT-IEKTDT 41,42,93,241 
DCS 16 

DCBDDNM field 16 
DCLIST-IEKTDC 80,241 
DCMPLX 35 
DCONJG 35 

DECB Skeleton section of IHCFIOSH 190 
DECK option 14,15,70 
DEFINE FILE 

statement 21, 42; 142 
phase 10 21 
format 148 

text 21 
Definition vector field 150 
Deletion 

of compilation 20 
before phase 20 15 
DELTEX-IEKQDT 109,241 
Depth numbers 57 

determination of 59 
DFILE-IEKTDF 41,45,93,241 
DFUNCT-IEKJDF 34,35,93,229,241 
Diagnostic message 228-232 

tables 

error table 80,141 
message pointer 141 
Diagnostic traceback 187 
DIMENSION statement 23 
Direct-linkage calling sequence 72 
Directory array 72 
Dispatcher subroutine 22 
Displacement for adcon 42 
Division skeleton instruction 170 
DO 25 

implied 25 

in strength reduction 67 
Double buffering 192 
DSPTCH-IEKCDP 22,23,85,241 
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DuiDmy argunitients 24 
DUMP 188 
Dump 2 34 
DUMP15-IEKLER 93,241 



EDIT option 14,15,21,22 
EMIN table 53 
Eminence table 53 
End mark operator 23 
End of DO IF 36 
End of file 20 
END Statement 13,20 

phase 25 processing of 75 
ENDFILE entry point 80,241 
ENDFILE statement 20,178,241 
END-IEKUEN 112,241 
Entry block 31, 37, 58 
Entry coding 

main program 18 

subprogram main 19 

subprogram secondary 20 
Entry placement subroutine 24 
ENTRY statement 20,31 
ENTRY-IEKTEN 112,241 
EPILOG- lEKTEP 75,76,112,241 
Epilogue 19,20,70,75 
Equivalence 26, 28 

group 23 
head 28 

variable 23 
EQUIVALENCE statement 

14,21,23,28,43,75,122 
EQVAR-IEKGEV 41,44,45,93,241 
ERCOM-IEKAER 8 
Error 

code table 76 

levels 20,76 

message processing 187 

object-time 177 

phase 10 response to 14 

phase 15 response to 15 

source statement, object-time 201 

table 14,76,80 
ESD entry point 81,241 
ESD record 46 
Execute statement 13,16 
Exit block 59, 61 
EXIT library subprogram 188 
EXT operator 162 

Extended error message facility 194,201 
EXTERNAL statement 2 3,35 
External symbol dictionary 13,15,46,69 



FAZ25-IEKP25 112,241 

FCLT50-IEKRFL 107,241 

Field count 26 

FILTEX-IEKPFT 109,241 

FIND statement 178 

FINISH-IEKJFI 93,242 

FIOCS,FIOGS# 80,242 

Fixed point multiplication skeleton 

instructions 169 
FIXPI,FIXPI# 80,242 
FLOAT 34 



FNCALL-IEKVFN 72,112,242 
FOLLOW- lEKQF 109,242 
Forcing strength 32-33 

definition of 32 

table 33 
Format 

codes with READ/WRITE 18 

of source statement after phase 10 22 

text 142 

phase 10 21 
format 148 
translation 26 
FORMAT statement 18,21,25,26,142 
FORMAT- lEKTFM 25,85,242 
FORTRAN system director 13,16-20 
Forward 

connection 30,37-38,39 
table 39,57 

target 64 
FREE-IEKRFR 107,242 
FSD 224 

pointer table (see NPTR) 
Full register assignment 47,226 

control 53 

global 51,52-55 

local 52-54 

0PT=1 51-55 

0PT=2 68-69 

table building 53 

text updating 53,55 
Full-word integer division skeleton 

instructions 170 
Function arguments 162 
Function table 35,135 
FUNRDY-IEKJFU 34,93,242 
FUNTBl 135 
FUNTB2 135 
FUNTB3 135 
FUNTB4 135 

FWDPAS-IEKRFP 53,107,242 
FWDPSl-IEKRFl 107,242 



GENER-IEKLGN 32,93,242 
GENRTN-IEKJGR 93,242 
GETCD-IEKCGC 21,85,242 
GETDIC-IEKPGC 109,242 
GETDIK-IEKPGK 109,242 
GETWD-IEKCGW 85,242 
GLOBAS-IEKRGB 53,54,55,69,107,242 
Global assignment 52-55 

full register assignment 0PT=2 68-69 

tables 139 
GO TO statement 

computed 21,70,134 

in gathering forward connection 
information 37 
GOTOKK-IEKWKK 112,242 
GRAVERR 76 



H format code 25 

Half-word integer division skeleton 

instructions 168 
Head of equivalence group 44 
Housekeeping section of IHCFIOSH 189-190 
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IBCOM,IBCOM# 80,242 

IBCOMRTN 20 

IBFINT 187 

ID option 70,115 

lEKAAA 16,80 

lEKAAD 80 

lEKAAOO 80,242 

lEKAAOl 80,242 

IEKAA9 20,80,242 

lEKAER 80 

lEKAGC 17,80,242 

lEKAPT 81 

lEKAREAE 85,242 

lEKARW 109,242 

lEKATE 80,243 

lEKATM 80,243 

lEKCAA 17 

lEKCBP 22 

lEKCIN 85,243 

lEKCLC 85, 243 

lEKCSl, CS2, CS3 85,243 

lEKFCOMH 18,80,243 

lEKFIOCS 18,80,243 

lEKGAl 95,243 

lEKGCZ 41,45,46,93 

lEKGMP 75, 113, 243 

lEKIORTN 80,243 

IEKJA2 243 

IEKJA3 95,243 

IEKJA4 243 

lEKJEX 94,243 

lEKJMO 93,243 

lEKKNG 94, 243 

lEKKNO 93, 243 

lEKKOS 27,85,243 

lEKKPR 93,243 

lEKKSW 94, 243 

lEKLFT 35,135 

lEKLTB 95,243 

lEKPBL 107 

lEKPOP 109 

lEKPOV 109, 243 

IEKP30 113,243 

IEKP31 113 

lEKQAE 109,243 

lEKTDC 8 

lEKTFM 86 

lEKTLOAD 18,19,81,244 

generating literal data text 26 

in relative address assignment 43 

space reservation 46 
lEKTXT 81, 244 
lEKUND 81,244 
lEKURL 81,244 
lEKUSD 81, 244 
lEKVLB 171 
lEKXRS 28,86,244 
ZEND 75,81,244 
INVERT-IEKPIV 109,244 
IF statement 23,24,31 
IHCADJST 177,187 
IHCDIOSE 177,195 

buffering 198 

communication with the control program 
198 

file definition section 198 

file initialization section 199 
operation 198-201 



read section 200 
routine directory 214 
termination section 201 
write section 200 
IHCERRM 177,194,203 
IHCFCOMH 45,72,177 

format code processing 179 
subroutine directory 209 
IHCFCVTH 177,188,209 
IHCFINTH 177,202 
IHCFIOSH 177,188 

closing section 195 

communication with the control program 

192 
device manipulation section 194 
initialization section 192-193 
read section 193-194 
routine directory 214 
write section 194 
IHCFOPT 204 
IHCIBERH 177,201 
IHCTRCH 177,202 
IHCUATBL 191 
ILEAD 40,130 
Implied DO 25 
INCNAMEL 177 
Index register 74 
Inert text entry 65,67 
Information table 14,17 
chains 119 

construction of 119 
operation of 

branch table 123 
common 121 
dictionary 120 
equivalence 122 
literal constant 122 
statement number 27,28,29,121 
components 21 

branch table 21,133-134 
common table 21,27,131-133 
dictionary 21,123-127 
literal table 21,133 
entries constructed by phase 10 23 
Initial value assignment 41,45 
Initialization 

of compiler 16-17 
of data fields 16-17 
of IHCFIOSH 192-193 
instructions, generation of 18-20 
In-line routine 34-35,161 

in branching optimization 56 
functions 158 

skeleton instructions 165-167,169-171 
Integer constants, elimination of 67 
Intermediate text 14,21,142-164 
chains 143-144 
phase 20 modifications 155 
Intermediate text entry 
format of 143 

modifications by phases 15 and 20 
149-164 
Internal statement number 14,22 

in phase 30 76 
Interruption 

processing 187-188 
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Interruptions 

arithmetic 187 

specification 187-188 
lOSUE-IEKTIS 72,112,244 
I0SUE2-IEKTI0 112,244 
I/O data list 31 
Input/Output device manipulation routines 

186-187 
I/O list items 24,181 

conversion routines 188 
Input/Output recovery procedure, 

execution*time 211 
Input/Output requests 

processing of 18 

request format 18 
Input/Output statement 24 

phase 25 processing of 71-72 
INVERT-IEKPIV 109 
ISN 14,22 



JLEAD 40,130 
Job statement 13 



LOC-IEKRLl 107,244 
Logical 

branch operations 157,164 

expressions 36 

IF statements 22,36 

in strength reduction 67 

skeleton instructions 170 
LOOKER-IEKLOK 94,244 
Loop 225 

composit matrixes 64 

identification 57 

number 60 
field 60 
parameter 63 

selection 63-64 
Loops 

depth numbers of 60 

identifying and reordering 60 

module 57 
LOR 35,236 
LORAN-IEKQLO 
LPSEL-IEKiPLS 
LXOR 35,237 



109,244 
48,53,55,62,107,244 



Keyword 

pointer table 117 
source statement 23 
subroutines 23 
table entry 23 
table entry and text 
table 117-118 
KORAN-IEKQKO 109,135,244 



23 



LABEL-IEKTLB 71,112,244 
LABTLU-IEKCLT 86,244 

in XREF 28 
LAND 35,236 
LBIT Operator 164 
LCOMPL 237 
LIBF operator 162 
Library function 35 

subprograms 177 
Linkage editor 13,15 
LISTER- lEKTLS 112, 244 
LIST option 14,15,70 

Listing, structured source program 62 
Literal 

data text 26 

table 133 
LMVF 64 
LMVS 64 
LMVX 64 
Load address 

operator 160 

skeleton instructions 168 
Load byte skeleton instructions 168 
Load candidate 74 
LOAD option 14,15 
Loader END record 69,75 
Local 

assignment tables 138 

register assignment 52, 54 

symbol 4 6 
Location counter 43,76 

in relative address assignment 42 



Main storage, requests for 

phase 10 17 

phase 15 17-18 

phase 20 17 
MAINGN-IEKTA 71-72,74,75,112,244 
MAINGN2-IEKVM2 112,244 
MAP option 15,70 
Map, storage 15,75 
MATE-IEKLMA 36,37,94,244 
MBM 136 
MBR 136 

MCOORD vector 27,45,53,138 
Message 

number 76,141,228-232 

processing 76 

tables 141 
Messages, error 

after phase 25 15 

phase 30 processing of 76 
MGM 136 

Microfiche directory 240-247 
Mid-point of dictionary chain 120 
Mode 23 

Mode field in status mode word 155 
MODFIX-IEKQMF 109,244 
MOD24 238 

MOVTEX-IEKQMT 109,244 
MSGM 136 

MSGWRT-IEKP31 76,113,245 
MSM 136 

Multiplicative text, elimination of 67 
MVD table 27,45,53 

in busy-on-exit 61 

entry 37 
MVF 27,36,37,151 

field 61 
MVS 27,36,37,151 
MVU 135 
MVV 135 
MVW 135 
MVX 27,36,37,151 

field in busy-on-exit 61 
MXM 136 
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NADCON table 39,42,118 

use in parameter list optimization 35 
Naitielist 

dictionaries 45,140-141 
entry 46 

text 45,142 

phase 10 21 
format 147 
NAMELIST statement 21,45,142 
NARGSV 36 
NCARD/NCDIN 22, 23 
NDATA-IEKGDA 41,42,94,245 
Negative address constants 44 
NLIST-IEKTNL 41,45,94,245 
Normal text 17,142 

phase 10 21 
format 145 
NOT 36 

Operations, skeleton instructions 167 
Not busy on entry, definition of 36 
NPTR 26,28,115-116 
Null operand 24 



Object module 

definition of 13 

elements of 69-70 

generation of entry code 25 
Operand 21 

modes 125 

status for code generation 73 

types 125 
Operator-operand pair 21 
Operators 21 

phases 15 and 20 152-154 
OPT=0 47 
0PT=1 47 
0PT=2 21 

structural determination 57-60 
Optimization 15 

first level 15 

levels 47 

none X5 

second level 15,21 
Option tables 205 
Options 

boundary alignment 177 

DECK 14,15,70 

determining 16 

EDIT 14,15,21,22 

ID 70,115 

LIST 14,15,70 

LOAD 14,15 

MAP 15,70 

SOURCE 22 

XREF 14,28 
OPICHK-IEKKOP 94,245 
OR 36 
Overlay 223-227 

supervisor 17 



optimization 35-36 
table 35 

processing of 16 
PAREN-IEKKPA 94,245 
PARFIX-IEKQPX 109,245 
PAUSE statement 172,187 
PERFOR-IEKQPF 109,245 
Permanent I/O error 20 
PHASE 80, 245 
Phase loading 17 
Phase 10 14 

constructing a cross-reference 28-29 

control 22 

initialization 22 

intermediate text 21 
Phase 15 15-16 

CORAL processing 16,41-47 

intermediate text 29 

PHAZ15 processing 14,29-40 
Phase 20 15 

Branching optimization 
0PT=1 55-57 
0PT=2 69 

busy-on-exit information 61-62 

control flow 4 8 

loop selection 63-64 

register assignment 
basic OPT=0 49-51 
full 0PT=1 51-55 
full 0PT=2 68-69 

structural determination 57-60 

structured source program listing 6 2 

text optimization 0PT=2 64-69 
Phase 25 15,69 

address constant reservation 70-71 

prologue and epilogue generation 75-76 

storage map production 75 

text conversion 71-75 
Phase 30 15,76 
PHASS 80,245 
PHAZSS 80,245 
PHAZ15 17,225 
PHAZ15-IEKJA 38,94,245 
PHIO-IEKCAA 17,86,245 
PH15-IEKJA1 95,245 
Planned overlay structure 223 
PLSGEN-IEKVPL 112,245 
Powers 34 

Preparatory subroutine 21, 22 
Primary adjective code 23,31 
Primary path 59,60 
Problem program save area 26 
Program 

fetch 17 

interruption mask 187 

termination 188 
Prologue 19,20,70,75-76 
PROLOG-IEKTPR 75,112,245 
Pushdown table 32 
PUTOUT 81,24 5 
PUTOUT-IEKAPT 81,245 
PUTX-IEKCPX 86,245 



PACKER-IEKTPK 112,245 
Packing 22 
PAGEHEAD 80,245 
Parameter list 



QSAM 16 
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Read 

not requiring format 185 
requiring format 184 
READ statement 178-18 6 
READ/WRITE 

operator for I/O lists 163 
routines 179-187 

examples of statement processing 
183-185 
statement 18,23,25,45,72 
using namelist 186 
REAL 3 5 
Real multiplication skeleton instructions 

170 
REDUCE-IEKQSR 67-68,107,245 
REGAS-IEKRRG 53,55,108,245 
Register 

array 72 
assignment 

basic OPT=0 49-51 
full 0PT=1 51-55 
full 0PT=2 68-69 
phase 20 47-57,68-69 
tables 138-139 
usage 139-140 
table 53-54 
Registers, 

reserved 18-19 

saving at main program entry 18-19 
saving at subprogram program entry 19 
Relational operators 36 

Relative address assignment 15,41,42-45 
Relocation 

dictionary 13,15,46,69-70 
factor 42 

of text entries for structural 
determination 57 
RELCOR-IEKRRL 107,245 
RELOPS-IEKKRE 36,94,245 
Reserved registers 56 
RETURN statement 61 

phase 25 processing of 74 
RETURN-IEKTRN 74,112,245 
Rewind processing 195 
REWIND Statement 178 
RLD 

entry point 81,245 
record 46 
RMAJOR table 37,40,57 
RM A JOR- 1 EK JA 4 95,246 
Root segment 15,223 
RUSE table 54, 138 



Save areas 18-20 
Scale factor 26 
SEARCH-IEKRS 108,246 
Secondary entry point 19 
Sequence numbers 24 
SF skeleton text 18,142 

phase 10 21 
format 149 
Shift skeleton instructions 169 
SHFTL 237 
SHFTR 237 
Simple stores 

elimination of 66 

example of 174 



Skeleton ' 

array 72 

instructions 73-74 
SNGL 35 

SOURCE option 22 
Source 

module, listing of 14 

program, structured listing of 62 

statement errors, object-time 201 

statement processing table 8 4 
Space 

allocation, phase 15 41 

reservation of adcon table 4 6 
Span 43,221 

Special argument text 162 
Special text 142 
Spill register 55 
SPLRA-IEKRSL 51,108,246 
SRPRIZ-IEKQAA 62,109,246 
SSTAT-IEKRSS 50-51,108,246 
STALL- lEKGST 22,86,133,246 

functions of 25-28 
Standard text, phase 15 format of 156 
Statement 

functions 31,32,142 
processing of 24 
skeleton 36 

number 

chain reordering 30, 38-39 
as a definition 30 
phase 15 format 150 
phase 25 processing of 71-72 
processing for XREF 28 
Statement number/array table 70,127-131 

block status field 129 

dimension entry format 130 

entry format 127 
after XREF 128 

after phases 15, 20, and 25 129 
Status 

field in status mode word 155-156 

information 48 

mode word 50 

of operands for code generation 73 

in register assignment 51 
STOP statement 178,187 
STOPPR-IEKTSR 112,246 
Storage distribution 

phase 10 17 

phase 15 17 

phase 20 18 
Storage map 

contents of 75 

production of 75 
Store skeleton instructions 169 
Stored constant 68 
Store-fetch information 124 
Strength reduction 67-68,106 

example of 175-176 
STRUCTURE statement 235 
Structured source listing 14,15,21-22 
STTEST-IEKKST 94,246 
STXTR-IEKRSX 51,53,55,108,246 
SUBADD-IEKKSA 34,94,246 
SUBGEN-IEKVSU 113,246 
SUBMLT-IEKKSM 34,94,246 
Subprograms 19-20,34 

not supplied by IBM 61 
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Subroutine directory 

FSD 80-81 

phase 10 85-87 

phase 15 93-94 

phase 20 107-108 

phase 25 112-113 

phase 30 113 
Subscript 

expressions 33-34 

absorption of constants in 221-222 

operators, skeleton instructions 168 

text entry 65,161 
Substitute ddnames 16 
SUBSUM- lEKQSM 66,109,246 
Subtract operations, skeleton instructions 

for 165 
Symbol entry for XREF 28 
Symbols, processing for XREF 28 
SYNADR routine 201 
SYSDIR-IEKAA9 20 
SYSIN data set 13-14,20 
SYSLIN data set 13-14,15 
SYSPRINT data set 13-14,15,21,28,29,62 
SYSPUNCH data set 13-14, 15 
SYSUTl data set 13-14,21,62 
SYSUT2 data set 13-14,28,29 



Table entry subroutines 2 3 
Tables used by IHCFIOSH 189 
TALL- lEKRLL 108,246 
TARGET-IEKPT 63-64,108,246 
TBIT 35,238 

TENTXT- lEKVTN 75,113,246 
Temporary 33 

in common expression elimination 65 

storage allocation in register 
assignment 55 
Terminal errors, object-time 202 
Termination of compiler 16,20-21 
Test and set operators 158 
Testing a byte logical variable 158 
Text 

additive text, elimination of 68 

block, definition of 31-32 

blocking 30 

conversion, phase 25 71-72 

data 21 

define file 21 

entry 

phase 20 format 155 
types 66 

format 21 

generation subroutines 24-2 5 

information, phase 25 70 

intermediate 21 

namelist 21 

normal,, phase 10 17, 21 

optimization 47, 64-70 
bit tables 135-137 
criteria for (table) 106 

SF skeleton 18,21 

special, phase 10 18 
TIMERC 80,246 
TNSFM-IEKRTF 107, 246 
TOPO-IEKTPO 57-59,107,246 
TOUT 80,246 



TRACE 233 

Traceback 202 

Translation of data text 42 

Tree notation, balanced 120 

Triplet 32 

TRUSE table 54,133,138-139 

TSP 80,246 

TST 80,246 

TSTSET-IEKVTS 113,246 

TXT entry point 81,246 

TXT records 25,70,81 

TXTLAB-IEKLAB 94,247 

TXTREG-IEKLRG 94,247 

TYPES table 64 

TYPLOC-IEKQTL 109,247 



Unary minus 32,34 

skeleton instructions 168 
UNARY-IEKKUN 34,94,247 
Undefined statement numbers 26 
Unit 

assignment table 189,191-192 
in IHCDIOSE 197 

blocks 18 9 

in IHCDIOSE 195 
UNRGEN-IEKVUN 113,247 
Usage count 25 
Use vector field 151 
Utility 

routines 187 

subroutines 24-25 
list of 109 



Variable, 

adcon 4 5 

base 45 

dictionary entry 123 

after common block processing 126 
after coordinate assignment 126 
after dictionary rechaining 125 
after relative address assignment 
after XREF 125 

equivalence 2 8,122 
Variables 

rechaining 27 

relative addresses for 42-45 



WRITE statement 178-186 

Write 

not requiring format 181,183 
requiring format 179,181 
section of IHCDIOSE 200 
to operator routines 187 
using NAMELIST 179 

WRITEX-IEKQWT 109,247 

WTO 187 

WTOR 187 



XARITH-IEKCAR 84,86,247 
XCLASS-IEKDCL 86,247 
XDATYP-IEKCDT 86,247 
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XDO-IEKCDO 86,247 

XGO-IEKCGO 87, 247 

XIOOP-IEKCIO 87,247 

XIOPST-IEKDIO 87,247 

XPELIM-IEKQXM 65-66,97,108,247 

XREF 

buffer 28,87 
option 14,28-29,123,127 
phase 10 preparation for 28 
processing 28-29,125-128 

XREF-IEKXRF 28-29,87,224,247 

XSCAN-IEKQXS 109,247 



XSPECS-IEKCSP 87,247 
XSUBPG-IEKCSR 87,247 
XTNDED-IEKCTN 87,247 



YSCAN-IEKQYS 109,247 



ZSCAN-IEKQZS 109,247 
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